Subject: Re: [linux-audio-dev] Re: [alsa-devel] Toward a modularization of audio component
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Fri May 04 2001 - 09:39:26 EEST
Paul Davis wrote:
>
> >In the past days I've thought a lot about whether, how and why current
> >alsa-lib PCM model is not suitable for all-in-a-process model (that
> >seems the only way to write applications with pseudo-RT needs).
> >
> >The result is the following simple proposal.
> >
> >The short resume is:
> >- every audio producer (a synthesizer, an mp3 file decoder, an hardware
> >capture stream, a .wav reader, etc.) have a PCM capture API
> >- every audio consumer (an mp3 file encoder, a .voc writer, an hardware
> >playback stream, etc.) have a PCM playback API
> >
> >Following this model, by example an FX plugin is an audio producer that
> >take as input one ore more audio producers.
>
> Its a cool (though not new) model.
I've never claimed it's a new idea and I'm not sure to understand why
you underline this.
> However, I don't think that its at all suitable as a model for a
> pseudo-RT system, which you appear to be aiming for.
Why?
> The thing that unites all their different approaches ?
>
> * an audio-interrupt driven model, in which a list of
> functions are called that cause the processing or synthesis
> of a specified number of frames of audio, and their delivery
> (if appropriate) to an output location.
This is exactly what happens with the model proposed.
> the ALSA PCM API is an excellent API for interacting with audio
> interfaces. However, I think its a much weaker API for handling audio
> in a way that is conceptually independent of an audio interface. Yes,
> I know that alsa-lib actually *is* independent of an audio
> interface. But its entire model of operation is rooted in concepts
> that stem from hardware.
I don't exclude that ALSA PCM API will need some adjustements to better
suit this model.
> just to mention one obvious problem with the ALSA PCM API interface:
> it doesn't enforce a standard sample format, which means that you can
> spend cycles converting sample formats (invisibly, perhaps, but still
> at genuine cost) between components that decided to use different
> conventions. this lack of an enforced format is clearly the right
> approach to take when interacting with h/w whose characteristics
> cannot be known ahead of time. but i think its wrong for a generalized
> psuedo-RT-streaming-audio-handling API. its why no audio plugin API
> uses this kind of flexibility, but instead they all use float (IIRC).
> and yes, i know that ALSA PCM API doesn't prohibit the use of
> float. my point is about simplicity versus flexibility. we have
> evidence, strong evidence, that we don't need very much flexibility to
> get the job done.
An audio producer/consumer may easily force a sample format and
contrarily to what you seems to affirm flexibility is good and not evil
if it comes cost free.
Please understand that we're discussing a way to reuse audio programming
efforts, and to use the same API for everything has huge advantages.
It's like to have several tools in your sound studio, but all have the
same connectors (this is the model I had in mind with this proposal, as
you see it's a very old idea ;-)
-- 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 : Fri May 04 2001 - 10:24:47 EEST