Subject: Re: [linux-audio-dev] LAAGA - main components
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Wed May 02 2001 - 01:18:16 EEST
On Tue, 1 May 2001, Jim Peters wrote:
> Stefan was talking about the need to have interoperability between
> LAAGA/AES/whatever and aRts and so on, so supporting out-of-process
> clients is necessary, even if it's just to connect to aRts. Also, all
If nothing else, we need to support multiple independent GUIs, and this
alone requires multiple processes -> some kind of IPC is needed.
> Personally, if I'm going to write an app, I'd be writing a plugin to
> go in the critical process, with another process outside dealing with
> the shared memory buffers. I don't care if it has a 100ms delay so
> long as my buffers are big enough to cope, because all the
> time-critical stuff would be in the plugin. The external process
> would just be GUI, front-end handling, data preloading from disk and
> data saving to disk. All of this can have 100ms delay without
> problem.
True. The audio data has to be created somehow, and often this means
making blocking calls. For instance, when streaming large files on a
smp-machine with 2.4.1 Linux kernel while under high load, execution time
for a single read() call typically varies between 1-700ms (40kB of data
per call). Now this is something very concrete. There's no magic way
around this than to have big enough memory buffer to cover the worst-case
delay.
I think we need to next focus more on the client side applications, ie.
what kind of different apps might benefit from LAAGA (ie. being in-process
plugins). It's clear that plain file streamer is not very interesting. You
just have a huge buffer, and a lower priority file-i/o thread and a
high-priority thread that can read from the doublebuffer without ever
blocking.
Now the interesting cases are ones where user interaction is involved in
the audio creation process. These are also the apps which benefit from
low-latency. In practise we need to stay below 5ms or otherwise human ear
starts to hear the delay.
It's probably possible to write the actual synthesizer code as a plugin
(ie. no system calls allowed). We might then have a GUI consisting of
knobs and sliders to control the synthesizing process. When control
values are changed, the results are written to a shared memory area where
the plugin can access them.
We'd still be using shared memory, but otherwise the plugin<->GUI-process
communication is different from the file streamer case. What about other
kind of apps?
> So I don't care about this 20ms delay. However, I can appreciate that
> some people might - especially people who have written fairly tight
> sound servers or whatever that need to be connected up. For this
> reason I've been putting in the effort to try and work out how we can
> make this fly as close to the ground as possible.
Yes, so basicly how to solve the plugin<->GUI-process communication
problem.
> My suggestion is to use shared memory, because this involves no costly
> system calls or library calls once it is all set up and running. The
> only issue then is how to handle an external process that wishes to
> wait on a shared memory buffer. I have made three suggestions, none
> of which have met any favourable response so far:
ALSA's aserver handles this in a different way: all data communication
is done through the shared memory areas, but notifications are sent using
sockets. There doesn't seem to be much information about aserver
available, but the code is short and sweet :) - check the ALSA CVS
tree:
alsa-lib/aserver/aserver.c
alsa-lib/src/pcm/pcm_shm.c
...
> calls at all in the critical process. Also, I don't think I'm going
> to be needing 20ms latencies in external processes. Anyone ?
Well, if you have a GUI-knob that affects the produced audio, you will
need a <5ms delay from changing the knob value to hearing the result. So
in this case 20ms is too much for the plugin<->GUI communication.
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Wed May 02 2001 - 01:08:26 EEST