Subject: Re: [linux-audio-dev] LAAGA - main components
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 01 2001 - 20:16:34 EEST
[ I have made the effort to not respond to any of your personal
attacks here. It doesn't help anyone to do that. ]
>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 agree with everything you've said here. However, both implicitly and
explicitly you seem to want add support for non-in-process clients. My
point about such things are they already supported by several
different sound servers, and its not clear to me that its a sensible
strategy to try and support both kinds of clients with the same
server. they work so differently.
>Note that this was a half-joke, so please don't bother to point out
>any fallacies in my suggestion.
since modifying the kernel is not a joke to some of us, i didn't take
your suggestion as a joke. however, my comment wasn't about the
kernel, but about the kernel API (typically accessed via libc). there
isn't a function call anywhere in the POSIX or Linux spec that permits
sleeping in the way you described. yes, you can always write a new
device driver that doesn't have any associated h/w. but this won't
solve the problem your were describing for reasons i've tried to
outline.
>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 ?
there's no way to know how long the write(2) call might block for, or
if it will block at all. so in general, no, its not OK. if it blocks
for more than the time-to-next-audio interrupt, we lose. it might work
most of the time. it might not.
>> 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.
Abramo has pointed out that the pcm_shm and aserver components to
alsa-lib *already* do this. Nothing new needs to be written to use
this, applications that already use alsa-lib don't need modifying, and
thanks to his work on libaoss, even OSS API-based applications can use
it to, with a little help from LD_PRELOAD.
So there isn't any work needed to support this kind of thing. The
question remains, as Kai showed very clearly a couple of days back, do
we support only in-process clients, only out-of-process clients, or both?
With in-process clients, what do we do about GUI's? If I understand
your suggestions and Kai's correctly, that would be down to the client
in question: how it and its GUI communicated would be a private
affair. Did I understand this correctly?
--p
This archive was generated by hypermail 2b28 : Tue May 01 2001 - 20:51:23 EEST