Re: [linux-audio-dev] LAAGA - main components

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

Subject: Re: [linux-audio-dev] LAAGA - main components
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Tue May 01 2001 - 19:00:06 EEST


Paul Davis wrote:
> >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.

You're off your trolley ! Are you reading what I've written ??? I'm
just repeating back to you what we've been discussing all this time.

> 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.

So you're saying: "AES is much better than that - it has a critical
process into which plugins are loaded to get really low latency".
Sounds like what I just said. Would you agree that we are discussing
the same thing ?

20ms is for external applications, assuming we can't find any kernel
tricks to improve that. But in any case, anything that wants better
than this will be a plugin in the critical process, running at 1ms
latency or whatever we can manage. This the low-latency process where
anything critical happens.

This critical process is where, in your example "taapir",
"terminatorX" and "ardour" all have their plugins installed, all
working at low-low latency.

I don't know what you're trying to do - the people on this list are
intelligent enough to understand what we're discussing, and I would
guess they're as puzzled as I am at your attempt to disrupt this
discussion without any good reason.

> >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.

Let me spell this out, because you obviously skipped a few important
words when you read that sentence. There is indeed no kernel call to
sleep on a shared memory location. If we wanted one we would have to
write it - hence my half-joke about *modifying* the kernel to achieve
that. It doesn't do it now, but through *modification* it might !
Note that this was a half-joke, so please don't bother to point out
any fallacies in my suggestion.

> you can sleep either by sleep(2)
> or poll(2) (or select(2). these all involve either time (which we've
> established is inadequate)

We haven't established that. Maybe 20ms is okay when everything that
needs 1ms latency is a plugin.

> 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().

Okay, this is something. In your experience with your low-latency
process, could we get away with making one write(2) call at the end of
the main loop in order to wake these other processes ?

> >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.

Well, shared memory is *very* fast, so even if we can't wake the
external processes right away, we're still saving system time that
would otherwise have been spent copying data in and out of a whole
list of buffers, which is what would happen if we used sockets or
pipes or whatever. We're also reducing the number of system calls in
the critical process to just one or maybe even zero (apart from
whatever it needs to talk to the audio hardware), instead of one for
every stream going in and out of the process.

I thought you were with me up to here ? Where did I lose you ?

Anyway, all of this is only to support low-load links for moving data
in and out of the critical process, and has got nothing to do with
what happens within the critical process itself.

Are we straight now ?

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim_AT_aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk


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

This archive was generated by hypermail 2b28 : Tue May 01 2001 - 19:42:18 EEST