Subject: Re: [linux-audio-dev] LAAGA - main components
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Tue May 01 2001 - 01:53:12 EEST
Paul Davis wrote:
> the problem is that you have to write to the busses in a time-synced
> fashion which means using kind of IPC. the audio thread has to very
> careful doing that. its not really about whether ALSA should support
> it or - it would be great if it did. its whether or not it can be done
> in a way that works for "less critical" apps as well as the ones that
> need 1ms latencies.
I can't see a problem with that. If we have a circular SHM buffers
for data moving to/from the critical process, then the critical
process will never have to block.
For less-critical apps that only output, they will fill their buffer,
and get ahead of time, whilst a time-critical plugin will empty the
buffer exactly on time. If the app needs to synchronise output with
some other event, then the app will have to give the time-critical
plugin a sample-clock time at which to release the buffer contents.
The same applies the other way around for less-critical apps that only
want to input.
For less-critical apps that wish to do both input and output, they
will have to define a latency when they connect. This is the amount
of input data they are fed before they are expected to have generated
some output. It is also the sample-clock difference between the start
times of the input and output SHM buffer plugins. Slower parts of the
system can be run at much longer latencies than the critical process,
especially if network connections are involved.
I can see how SHM can work smoothly without need for semaphores and
without risk of races or other weirdness for most of the time, but
there is a problem for the app when the buffer is empty on input or
full on output. At this stage it should block. There are two choices
- either get it to estimate when the buffer may be ready again and
sleep, or get it to request a signal of some sort from the critical
process. This might be a real signal, a semaphore, a byte over a pipe
- but all of these involve some overhead (although not a risk of
blocking) for the critical process. Maybe the estimated sleep will
work well enough.
That is the only tricky bit I see in it so far.
By the way, if the critical process ever finds a full buffer on
writing, or empty buffer on reading, then this is an ERROR, and it
will have to do something unpleasant, like disable the channel, or
insert a good-sized chunk of white noise, so that you are sure to know
that something has gone wrong. I hate it when mobile phones fill the
error blocks with silence. If they'd just put a recognisable tone in
there you would know what had happened.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Tue May 01 2001 - 02:38:21 EEST