Messages in this thread | | | Date | Fri, 23 Jul 1999 23:46:53 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
Benno Senoner wrote: (...) > > >Yep, I know, and fixing that might be enough. However, is that enough to > > >guarantee that a real time task will get control within any defined > > >time? I want figures. Hard, real, reliable figures. > > I think the can't give a mathematical proof, of upper-bound latencies, > that's why I created my latencytest benchmark. > Running this benchark with stressing the machine as much as possible, > for a long time , and getting NO DROP outs means a RELIABLE RT APP for me. > Call it hard-realtime, soft-realtime , firm-realtime, but what matters > is if the deadlines are meed under high system load or not.
I agree here. For real time audio to be useful, it must be possible to do while loading the rest of the system heavily. And any audio system that occasionally dropps a buffer is not much better than a Windoze based solution, even if it doesn't crash. Upset musicians will take care of that instead... ;-)
(...) > I think it this problem will not be fixed soon ( <1 year) , then Linux will > miss it's chance as a MULTIMEDIA OS. > And that's not compatible with the term "world domination". > :-)
And that in turn, is not compatible with having fun with low latency audio processing. ;-)
> I'm just curious how AMIGA plans to solve these issues , > using a RT-Linux scheme or a firm-real-time scheme ala KURT ? > > I think under QNX, this would be very easy, > just run the audio driver, and your RT app at higher priority, than > other driver et voila. (one of the advantages of microkernel) > :-) > > RT Linux sounds nice to me, but without memory-protection, > runnnig audio-plugins, becomes very dangerous (look at DirectX), > if there is a bug, the poor Linux box gets down. > At least I would prefer, a crash of the audio engine, which you can > restart again.
Agree, but if I can chose between unreliable 20 ms latency (at the very least) and NO WAY to avoid crashing every now and then even if all plug-ins are "bug free", and rock solid 3 ms latency (or whatever I like) and the possibility of a crash when using a buggy plug-in, guess where I'll go...
Besides, the memory protection problem WILL be addressed in one way or another. If no one else cares, I'll just have to hack it myself when I get tired of hard-testing all plug-ins in user space before using them in the RT engine.
> And I agree with Paul, a MIDI sequencer or soft-syth is an app ,which need > to make systemcalls AND must run with some time constraints. > Some plugins could run in the Audiality context, > but other parts of the program must run as soft-REAL time app, > and it would be nice if the soft-realtime part stays under the 5ms mark all the > time. > > comments ?
What kind of system calls? What resources need to be hard real time in addition to audio and MIDI ports? I can understand if you want to use some non-standard devices for soft real time control of an audio application, but audio and MIDI devices will be hard real time capable, and a basic set of "routing" plug-ins will handle the usual stuff like real time MIDI processing and mapping. Passing events as out-of-band data between an application and Audiality will off course be possible, but that's soft real time as long as Linux is... Good enough?
I think an intelligently composed set of hard real time plug-ins that applications can control through real time events (much like a hardware synth, but a lot more flexible) will open up some quite interesting possibilites. And it'll work as soon as the code is usable. The "user annoyance factor" of the current timing problems with Linux will be reduced far below anything that runs on Windoze or Mac now.
What did I miss here? More detailed explanation of my ideas needed?
I want all weknesses pointed out ASAP, so I can get everything right from the start. ;-)
> > regards, > > Benno Senoner > E-Mail: sbenno@gardena.net > Linux scheduling latency benchmarks > http://www.gardena.net/benno/linux/audio
//David
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |