Subject: Re[2]: [linux-audio-dev] One API for everything (first draft)
From: Rick Burnett (destinytech_AT_spacey.net)
Date: Sat May 19 2001 - 21:30:53 EEST
I have been following this discussion and also agree that I do not see
the advantage of implementing a multitude of internal sample handling
data types. It just seems to me that doing this would cause
compatibility problems between plugins even if conversions occur. If
95% of the application are going to use floats, then it only seems
reasonable that you would want to cater to the majority because
1. The API will be easier to understand and use, less worrying about
implementing for multiple data-types or worrying about conversion.
2. Floating point operation has become incredibly fast, especially on
the AMD Athlons which have superior FP performance compared to the
Pentium lines.
3. Graphic APIs that I have used all work with floats (OpenGL, GLIDE)
because it simplifies the core functionality, and can be scales well
because of its greater precision into other data formats.
The only place I can see where other datatypes would be wanted ( from
streaming audio ) would be on inferior devices ( like ARM processors
that have no floating point unit ). I argue though that from what I
understand, we are trying to build an API that is powerful and simple,
I think that answers the question in my mind.
But, thats my thoughts that I wanted to add. I like flexibility, but
bounds to the API increase functionality across developers.
FWIW,
Rick
Saturday, May 19, 2001, you wrote:
>> > > 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".
>>
KM> What I call them is not important - what is important is that they are
KM> different concepts. Some work on streams and some do not - this is an
KM> important difference that cannot be easily abstracted.
KM> [ discussion about single/multiple sample formats]
KM> All of this has been debated over and over again. I disagree with you,
KM> but see no way to convince you. Perhaps other people will comment at this
KM> point.
KM> 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!
>>
KM> _____________________________________________________
KM> | Karl W. MacMillan |
KM> | Computer Music Department |
KM> | Peabody Institute of the Johns Hopkins University |
KM> | karlmac_AT_peabody.jhu.edu |
KM> | mambo.peabody.jhu.edu/~karlmac |
KM> -----------------------------------------------------
This archive was generated by hypermail 2b28 : Sat May 19 2001 - 21:40:39 EEST