Subject: [linux-audio-dev] Reinventing the wheel
From: David G Matthews (dgm4+@pitt.edu)
Date: Fri May 04 2001 - 18:04:29 EEST
Paul,
Will a transcript or audio clips of your talk be available online? I'm
very interested (and I'm sure others would be too) in what you have to
say.
-dgm
On Thu, 3 May 2001, 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.
>
> 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 - 18:37:43 EEST