Subject: [linux-audio-dev] Re: [alsa-devel] Re: laaga, round 2
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Wed May 09 2001 - 00:15:24 EEST
Jim Peters wrote:
>
> 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 ?
The engine may easily choose which ready condition are not mandatory and
act exactly as you describe.
A very good point, I've appreciate it very much....
> > - 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 ?
Note that HW audio components works already in this way, I've extended
the same model (like in alsa-lib where I've found it very comfortable).
>
> > - 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 draw a scenario: we are developing an hard disk recorder application,
and we are using a big intermediate buffer for writing. Suppose that for
some reasons this buffer becomes full, I see the following alternatives:
a) abort application (!)
b) wait for some space on buffer and hope that this will not cause an
xrun
c) discard audio data (?)
c) other more complex tricks?
So I think that it's not a blasphemy to assert that some engine may
choose b).
-- Abramo Bagnara mailto:abramo_AT_alsa-project.orgOpera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org It sounds good!
This archive was generated by hypermail 2b28 : Thu May 24 2001 - 04:38:56 EEST