Re: [linux-audio-dev] various nags

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] various nags
From: rob (rob_AT_kaybee.org)
Date: to elo    12 1999 - 11:37:05 EDT


        the ones you've mentioned cover pretty much all my major concerns.
problem one is relatively easy to implement. the easiest least intrusive
way to do it i think would just be to allow editing via cut/play lists and
then have the editor apply those to create the final saved file.
        the second issue is i think the most difficult and important.
linus et. al. have stated (iirc) that they don't really intend to cater
to every group who wants a kernel feature added to make their lives
easier. so we should make some noise at them but be prepared to do
without.
        i think rtlinux is still the most promising. audio drivers will
need to be written to live in the realtime part of the kernel, so the
available number of cards will be limited...on the other hand perhaps an
OSS boot can provide an enviroment that existing drivers can be added to
the real time level...ie we make the audio subsystem live in the rt
kernel, not the linux kernel.
        we can then provide sample accurate feedback to the application as
to what the sound card is doing similar to sgi's implementation and can
put some scheduling capabilities on the realtime level to insure on time
delivery of events. the biggest problem with this is that at least some
of the sequencing code has to live in the realtime code which is
inherhently dangerous. on the other hand we could make a further hack
that allows timers and enforced scheduling to call an application's
callback to run. the callback however would be limited in it's ability to
make system calls. (is this an adequate compromise ?)
        perhaps all that need live in the rt level is a few timers which
will tell the linux scheduler what must be done "now"...this would require
a bit of kernel hacking but might be the cleanest way.
        no matter what it will require a bit of study to figure out how to
best do this.
         that said, i would prefer to have a single decent digital IO card
supported and a single midi IO card, rather than alot of cheaper cards
available with questionable performance. this is not the ideal situation,
but it seems more realistic in actually being accomplished.
        on a side note, i really want some usb interfaces to be supported
so that one could use a laptop alone to control synths and record...thats
what i really want.
        anyway.
        harddrive interrupts may still have to be addressed (not for rt
support but because any daw system interacts heavily with the filesystem
and the audiosystem).
        the final problems are less of a technical challenge and more of a
straightforward organizational effort and just basically sitting down to
write the code. i'm sure we can still easily argue for days as to just
how to go about it.

                                rob

On Thu, 12 Aug 1999, Dave Phillips wrote:
> Problem 1. We need a soundfile editor that can handle arbitrarily
> large files.
> Solutions: Can any of the existing editors (MiXViews, DAP, Snd, etc)
> be retrofitted for that capacity ? What would be involved ? Should the
> attempt be skipped in favor of a whole new editor ? I agree with Adam
> Zygmunt that this a very serious issue.
>
> Problem 2. We need to resolve issues of latency and dropouts caused
> by system activity. It will make no difference how cool our software is
> if dropouts kill its efficiency. Maybe I can get by with one or three
> minute files now, but what will happen with my 20-minute pieces ?
> Solutions: RTLinux ? A customized kernel for audio ? Can we fix the
> existing kernel to adapt to audio concerns ? It seems to me that this is
> also a most important concern: has Alan Cox been apprised of its
> significance ? The kernel developers must take note of this problem, and
> audio should not be left as a sort of backwater concern. Put it out
> front, don't let sound matters remain secondary or even tertiary
> concerns in kernel development. And I'm not just talking about drivers
> here ! ;)
>
> Problem 3. We need a good basic MIDI and/or audio sequencer.
> Solutions: Jazz++ ? Multitrack ? Something not yet seen ? Multitrack
> is slated for open-source, but will it fit the need ? Jazz++ is not
> open-source, but its developers may be responsive to suggestions
> regarding its stability and use. Is there another project more deserving
> of developers' focus ?
>
> Problem 4. There are perhaps too many projects undertaken and not
> enough cooperation. IMO, we need to focus on the development of only a
> few superlative applications instead of any number of private projects,
> no matter how nice those projects may be. Without the larger-scale stuff
> Linux will never be consider a serious audio development and composition
> platform.
> Solutions: Make more project leaders aware of LAD and the Csound
> UNIX/Linux Development group. Contact each other, write to start-up
> project leaders, ask what their goals are, see whether we aren't
> re-inventing the wheel. For instance, just how many audio and audiofile
> libraries are out there now, but how many do we really need ? I should
> think that one or two could provide all necessary services, provided its
> design considers everything needed by common (or even uncommon) audio
> applications.
>
>
> I have a pet project that I would like to see come to pass. I want to
> make the NoTAM applications capable of handling large files, and I want
> their feature sets to be completely working (especially in Mix). I would
> have a pretty slick composition/processing environment with Csound,
> Ceres, and Mix, but only if the issues of file size and record/playback
> latency are resolved. Csound 3.57 is impressive enough already, but I'm
> not sure Cecilia will work with it. Ceres and Mix have well-known
> problems and they are being addressed, but I wonder whether they can be
> fit to modern needs.
>
> Okay, just kicking things around here. As always, comments and
> criticism are welcome...
>
> == Dave Phillips
>
> http://www.bright.net/~dlphilp/index.html
> http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html
>

Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob_AT_kaybee.org, gt4255a_AT_prism.gatech.edu


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST