Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Sun May 06 2001 - 11:41:06 EEST
Abramo Bagnara wrote:
> Just think to my -----> as functional link (all the things I've drawn
> are in the same process) using ALSA PCM API, and then you get what
> you've drawn (if I assume that +---+
> | |
> +---+ is the process boundary).
> But with some differences:
>
> - you assume that plugin chain is something that engine need to know
> statically, while I say that engine get audio from zero or more producer
> and put audio to zero or more consumer independently from what is hidden
> behing them.
No, I'm expecting the connections between plugins to change
dynamically, but relatively infrequently compared to the cycle period
(which could be down to 1ms) so that we get a chance to reorder the
run-list when connections change.
> - a related difference is that you put at extremity two hardware while I
> say that's not necessarily true.
Okay, agreed.
> GUI visual scope
> +------||-----------||-------------------------------------+
> | audio_producer1 ----\ |
> | audio_producer2 -----\ /-- audio_consumer1 |
> | > engine < |
> | audio_producer3 -----/ \-- audio_consumerN |
> | audio_producerN ----/ |
> +-------||-----------------------------------||------------+
> appl file writer thread
I think I understand the direction you're coming from now. This is
the same approach that Paul has been taking in AES. I'm guessing that
you intend that an audio producer might write to any audio consumer at
any moment, without much warning.
This is fine when there are only producers or or consumers, but if any
consumer is also a producer, this puts a cycle-period delay in the
flow of audio. This means that if, say, we have two units - a reverb
and then a master EQ - and we are sending all the output audio through
both of them, then this inserts two cycle-periods of delay into the
signal chain, which is not good when we are aiming for low-latency.
If you can't see why this should be, then consider the order of
execution - first we need to run all the producers to get the data for
the consumers to process. Our reverb doesn't have it's input data
yet, though, so it has to use the data from the previous cycle. Same
with the EQ unit.
The only way around this is to give up the notion of any producer
being able to write to any consumer at any given moment. If we insist
that producers give us some warning of which consumers they wish to
write to, and give us a chance to reorder the run-list (a few ms),
then we can arrange for the reverb to get its input data before it has
to generate output - same with the EQ - eliminating the two-cycle lag.
What I'm saying here also answers some of the issues raised one of the
threads discussing with Paul, so perhaps this should be on that
thread, but it seemed appropriate here as we were comparing models of
how to understand this server.
As to whether the ALSA API is appropriate for use within the process,
I'm still very doubtful, but I'm wondering if I should try to read up
on the details of this. Is there any documentation up-to-date enough
to be useful for me to read ?
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Sun May 06 2001 - 12:41:08 EEST