Re: [linux-audio-dev] CSL-0.1.2 Release

[Abramo Bagnara <abramo alsa-project org>]

Paul Davis wrote:
> 
> In message <20010607002228 10931 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 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!