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

[Paul Davis <pbd Op Net>]

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

If the API you're talking about is ALSA, then I totally agree with
you. ALSA *is* a HAL, and its appropriate for it to contain these
aspects in its design.

That doesn't mean that a HAL is the right API for applications that
want to play or record audio data. I believe there is evidence (from
other systems and introspection (!)) that the right level for
applications is "above" a HAL, not a wrapper around it.

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

Thats not true. DirectX provides no equivalent method to
snd_pcm_rewind(), and neither does IRIX, nor does Mac OS X, and all
these systems do/have/will support games. If John believes this, its
because he doesn't understand how to do without it in the context of
the applications he writes. That doesn't mean its necessary, it means
that game writers have designed their application architectures around
the existence of such a function. The challenge faced by game writers
is no different from the one faced in a low latency application
running a LADSPA plugin to modify an audio stream. They just happened
to have designed their applications in a way thats very different from
the approach taken by most audio programmers.

As for:

>mypcm:RATE=44100,CHANNELS=2,FORMAT=S16_LE

this is exactly the sort of stuff I want to see consigned to the
darkest, lowest levels of an audio API. ALSA has been so influenced by
OSS in this regard that I think we lost track of something
important. If OSS had looked more like the IRIX audio I/O library, I
think ALSA would look very different today, for example. That library
only supports float32 data, for example.

--p