Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Sat May 05 2001 - 11:21:44 EEST
Jim Peters wrote:
>
> Abramo Bagnara wrote:
> > Please remember that ALSA PCM API can work in both way:
> > - single-thread audio engine design (using ALSA PCM API as a
> > communication interface between in core components and an engine that
> > gives the impulses)
>
> Okay, you're proposing that we use ALSA calls to transfer the audio
> data between LAAGA plugins, all in the same thread, right ? So, this
> will make one small part of the code look standard. However, these
> plugins will still have had to have been written specially for LAAGA
> so that they can fit in to the LAAGA plugin environment, and be
> scheduled along with other plugins, and follow special LAAGA
> guidelines to make sure that they don't disrupt the low-latency
> responsiveness of the thread.
>
> So, if so much has to be different, what gain is there to transfer the
> internal audio connections within the thread through the ALSA API ?
> We might as well just pass it around in the nearest handy buffer, as
> everything else is so specialised. I can't see the point of applying
> the general solution of the ALSA API to such a specific and
> well-defined case.
>
> However, I have no problems with the idea of using the ALSA API to
> allow external independent applications to connect to the server,
> because these applications would not have to provide plugins, and are
> not under such rigid low-latency constraints.
>
> Does this give some kind of satisfactory technical response to your
> suggestion ?
I think there is some misunderstanding, the solution I proposed for
single thread audio engine is the following:
audio_producer1 ----\
audio_producer2 -----\ /-- audio_consumer1
> engine <
audio_producer3 -----/ \-- audio_consumerN
audio_producerN ----/
Every audio_producer may obtain audio data from zero or more other
audio_producer (not present in diagram), same for audio_consumers.
Every link uses ALSA API. Engine does not know anything statically about
it's producer and consumer, they often will be an user choice.
>
> > I think that now we have enough experience (distributed on several
> > brains, as we like it ;-) to design an architecture that permit all this
> > and I'm sure that this would bring great benefits for consumer audio and
> > *huge* benefits for professional audio.
>
> I really hope we can pull this off and create a rock-solid and
> easy-to-use low-latency plugin environment. As you say, the full
> solution is distributed amongst several brains, each of us with a bit
> of the answer. Praying that this may go smoothly ...
How I say often to my sometimes frustrated childrens, our motto is
"trying again and again" ;-)
-- 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 : Sat May 05 2001 - 11:49:42 EEST