Subject: [linux-audio-dev] Re: [alsa-devel] Re: laaga, round 2
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Tue May 08 2001 - 22:55:51 EEST
Abramo Bagnara wrote:
> The engine loop is driven by their consumers/producers ready condition.
> (yes, multiple conditions).
There are certain things you suggest that are not at all compatible
with what I regard as necessary for a pro-quality platform for audio.
This is one of them. This would mean that if not everything is ready,
then we could skip a block of output to the hardware or drop a block
of input data. This seems to me to be unacceptable.
This means crippling the whole system due to inefficiency in perhaps
only one small part. Let's say we are using ardour for HD recording
in a music studio. The band have got 3 minutes into their song, and
some unexpected delay on the disk causes the guide track to falter.
According to your design, the whole engine pauses whilst we wait for
this, and we lose a moment of the recording, which renders the whole
recording worthless. Any audio platform behaving like this in a pro
studio environment will deservedly be thrown rapidly out the window.
My rule is this: the engine must continue at all costs. If some
plugins can't keep up, that's their business. They must insert
silence, or report an error, or disable themselves - do whatever seems
appropriate, but *not* stop other plugins from carrying on with their
work. Time doesn't stop, the hardware doesn't stop, so why should our
engine stop ?
> - communication between components is achieved using ring buffers in
> shared memory
In another posting you also mention using ring buffers for
communication in-thread. But why ? This suggests that you are
allowing for some variance in execution times which the ring-buffer
can absorb. But where is there room for this variance when we may be
working down to 1ms latencies ?
> - disk access is done by separated threads using large intermediate
> buffers. Sometime the engine will need to wait r/w completion ...
No, no - can't accept this - see above.
I know that I'm picking out points on which I disagree with your
approach, and not putting emphasis on points on which we agree, but
these things you say suggest that you are designing for a situation
with much greater tolerance for errors and variance than exists in the
kind of target application that I'm interested in.
Okay, maybe very many applications won't need these kinds of tight
tolerances, but then they don't need to be plugins in our server
either. Instead they can connect via shared memory ring-buffers to
standard plugins designed for communicating with external processes.
They still get the benefits of interconnection, but without the low
latencies and strict requirements of a plugin.
We need to design for the most demanding application if this is going
to be a genuinely useful server.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Thu May 24 2001 - 04:52:53 EEST