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: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Sat May 19 2001 - 19:48:53 EEST


Karl MacMillan wrote:
>
> 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.

But, note what... you've called them always "port".

I deduce you agree that "ports" may see to pass through different kind
of objects. This is my point and this is supported by my API.

> > 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

This is where we disagree (but this does not change anything in API).

> - increases component compatability

I agree that 95% of professional plugins should be written for float
sample format.

> - simplifies the api

Nope, we need to cope with port data format nevertheless.

> - makes everything more efficient

Nope, it's irrelevant. The plugins works at exactly the same speed.
The plugin (a soundbox) say to application "Hey, I can handle only
float". That's all.

>
> 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.

Efficiency:
- an integer sum cost 1/2 of a float sum IIRC.
- sometime we are so near to hardware that to change samples to float
and at end convert it back is needless expensive

> 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).

While I'm talking of *all* audio components (yes, also soundfile
reader/writer). They're soundboxes.

-- 
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!


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 - 20:24:08 EEST