Subject: [linux-audio-dev] Re: [alsa-devel] Toward a modularization of audio component
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri May 04 2001 - 03:28:18 EEST
>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.
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.
In Firenze in a few weeks, I'll be giving a talk called "2 Years
Reinventing the Wheel: Linux as a platform for pro-audio". I think
I've spoken about this here before. I want to encourage people to get
over their (and my) somewhat instinctive "not invented here" mentality
when it comes to audio programming.
Steinberg, Digidesign, Emagic and several others have all figured out
how to do this stuff. They've been doing versions of it (incomplete,
to be sure) for years.
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.
that leads to a very simple interface. the AES example i posted
earlier today shows just how simple it can be (actually, i made it
*more* complex to gain some efficiency/performance). LADSPA makes it
even clearer how simple it can be.
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.
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.
Read about ReWire, in particular. Read about ASIO. Read about TDM,
EASI and a long list of other acronyms. We don't need to reinvent all
this stuff.
--p
This archive was generated by hypermail 2b28 : Fri May 04 2001 - 04:04:53 EEST