lkml.org 
[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.104 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site