Re: [linux-audio-dev] One API for everything (first draft)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] One API for everything (first draft)
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Sat May 19 2001 - 18:24:05 EEST


On Sat, 19 May 2001, Abramo Bagnara wrote:

> Karl MacMillan wrote:
> >
> > On Sat, 19 May 2001, Abramo Bagnara wrote:
> >
> > You have misread this message. This was referring to control data while I
> > was referring to sample data. I think most people are in agreement that
> > supporting more than one type of sample data is a very bad idea.
>
> A port is a port is a port.
>

This is clearly not true - there is a big difference between a port that
accepts a single float value occasionally to change a parameter, a port
that accepts a midi stream, and a port that accepts a large number of
samples.

> > > To have a property for sample format does not imply that every plugin
> > > need to implement it.
> > >
> > > query_property is there to permit to know that (as an example) this
> > > specific plugin can handle only float data.
> > >
> > > We can deduce that also from set_property failure.
> > >
> > > Please don't confuse flexybility with complexity.
> > >
> >
> > We seem to continually have this argument. Complexity is not flexibility
> > when it provides no real benefits. Multiple sample formats _between_
> > components provides no benefits for users or programmers.
>
> If you limit the semantic of "component", maybe...
>
> But as my aim is to have *one* object (soundbox) class for every
> componet your argument is bogus: some soundboxes will never accept
> float.
> (and some soundboxes will accept *only* float)
>

The semantic of component is limited already - both LADSPA and the
proposed LAAGA are about the exchange of audio data between components.
This, to me, is a reasonable limitation on the scope of the api and given
this limitation choosing a sample format of floats for all components

 - increases component compatability
 - simplifies the api
 - makes everything more efficient

I can think of no reason to deal with samples in any format other than
floats. Previously the use of MMX might have been compelling, but now all
of the vector units in modern cpus can operate on floats (SSE, Altivec,
3Dnow). What benefit do you see to exchanging samples in some format
other than floating-point? The downside to multiple formats seems clear
to me, so I am curious about what you see as positive.

Also, I want to emphasis that I am only talking about exchanging samples
between applications. Within an application there may be compelling
reasons to use some other formats (like a soundfile reader or writer).
This is analoguos to pipes - under your system a user might get the
equivalent of

> cat file | grep "foo"
Error: grep does no understand format "signed char"

This is clearly not what a user wants to see - they just want to be able
to send the output of cat to grep. A single sample format garuntees this
will happen without expensive implicit conversions.

Karl

> --
> Abramo Bagnara mailto:abramo_AT_alsa-project.org
>
> Opera Unica Phone: +39.546.656023
> Via Emilia Interna, 140
> 48014 Castel Bolognese (RA) - Italy
>
> ALSA project http://www.alsa-project.org
> It sounds good!
>

_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| mambo.peabody.jhu.edu/~karlmac |
-----------------------------------------------------


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat May 19 2001 - 18:50:15 EEST