Subject: Re: [linux-audio-dev] LAAGA - main components
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 01 2001 - 13:58:23 EEST
>Let's say the buffer has enough room for 100ms of sound. The app will
>be at most 100ms ahead of real-time, but depending on other CPU
>activity, it may get behind, but hopefully not as much as 100ms behind
>or else we're in trouble.
Now you're already wandering away from the point of LAAGA. See below.
>If the minimum sleep is 10ms in the worst case, then this just means
>that external apps had better allow themselves 20ms latency at least.
>If they need better than that, then they'd better load a plugin into
>the critical process.
>
>Does this sound fair ?
Well, it sounds fair, but its not relevant to the original goals.
We already have sound servers: esd, aRts, aserver and others. The
problem with all these solutions is that they don't support low
latency operation. So if you want to do real-time FX work with (say)
Maarten's taapir, some dj-ish work with terminatorX and record it all
with ardour, you can't.
AES is an initial implementation of an idea thats been floating around
here for a year or more, and is present in several windows/macos
systems: that to share an audio interface in a low latency context,
you have to have all the clients being in-process.
20ms latency is just totally unacceptable for real-time work. So this
method doesn't really offer any distinct advantages over the existing
sound servers that already exist, and it also doesn't support the low
latency situation.
>The other way might to modify the kernel to permit sleeping on a bit
>in shared memory ! Hmmm. Basically, what we want is at the end of
>the critical process main loop, when it is once again blocking on the
>audio input and the process context changes, at that point we want to
>wake up all the processes that may be waiting on the shared memory
>buffers.
you seem to be missing something here. there is no kernel call to
"sleep" on a shared memory location. you can sleep either by sleep(2)
or poll(2) (or select(2). these all involve either time (which we've
established is inadequate) or a file descriptor. with a file
descriptor, we already have the mechanism in place: i'm not quite sure
how kernel 2.4 has changed this, since we now have wake-one semantics
for some things, but previously (and now presumably either by default
or with some flag setting), the kernel wakes all threads sleeping on a
file descriptor when it executes kill_fasync().
>If even that single system call at the end of the critical process
>main loop is still too much of a risk, then we're down to a choice of
>kernel mods or 20ms+ delays for external "less-critical" apps, unless
>someone can think of some other way.
why build all this infrastructure to merely duplicate the
functionality of existing sound servers? the goal (i thought) was to
support new functionality that is only possible with in-process
clients.
--p
This archive was generated by hypermail 2b28 : Tue May 01 2001 - 14:45:29 EEST