Subject: Re: [linux-audio-dev] CSL-0.1.2 Release
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Thu Jun 07 2001 - 10:04:35 EEST
Paul Davis wrote:
>
> In message <20010607002228.10931_AT_space.twc.de>you write:
> >CSL-0.1.2 - the Common Sound Layer - has been released.
> >
> >The scope of CSL can roughly be summarized as:
> > Helping all applications out there that currently contain a
> > variety of platform specific notoriously non-portable audio code.
> >
> >On the one hand, CSL provides sufficient abstraction of platform specific
> >details, where we took extreme care to maintain full-fledged access to
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >the features offered by the APIs being wrapped, such as:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I consider this to be a serious design error.
>
> Every (commercial) player in the computer audio world has apparently
> learnt the following lessons about audio APIs:
>
> * use a single common audio data format
> * use a callback model
> * remove almost all hardware related concepts from the API
>
> Wrapping a Hardware Abstraction Layer (HAL) like OSS or ALSA in what
> is really just another HAL with the same semantics but different
> function names doesn't move us forward. Instead, it just provides
> developers with yet another choice to make, and continues to force
> them to work with details of audio that they should not have to care
> about.
>
> The "LAAGA" API that we've been discussing on LAD is precisely about
> moving above and beyond all this stupid hardware/device/parameter
> stuff and enabling developers to focus on functionality in a way that
> is totally different and vastly more functional than the kind of
> low-level audio i/o API offered by CSL as well as the APIs it wraps.
I think you're making a mistake here.
Although I agree that many application don't need/want to cope with
hardware/software setting this is not a good reason to remove this
capability from API.
The right solution is to make it optional. I describe the solution I'm
implementing for ALSA:
I've just implemented parametric configuration that will permit to open
a PCM called:
mypcm:RATE=44100,CHANNELS=2,FORMAT=S16_LE
and do what you expect from it. Without any needs to change settings.
Other applications may need to change their settings on runtime.
A make another example: very few application classes need snd_pcm_rewind
but to remove it would be a great mistake. Games *need* it to do a good
job (as I've verified with John Carmack and others) then to remove it is
simply wrong.
A good API need to be a complete one, while retaining its simplicity.
This is the lesson I'd like you agree on.
-- Abramo Bagnara mailto:abramo_AT_alsa-project.orgOpera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org It sounds good!
This archive was generated by hypermail 2b28 : Thu Jun 07 2001 - 10:41:33 EEST