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

[Paul Davis <pbd Op Net>]

>> >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.
>
>ALSA is much more than a HAL as you already know: it's an API versatile
>enough to talk *also* with hardware.

Its design is 100% inspired by the operation of the hardware it can
*also* talk to. It doesn't abstract that away at all. 

>This is exactly the key concept I'd like you note: "versatile enough".
>
>I insist that a right API need to have methods to get/set/query
>properties for underlying objects.

As long as we continue to promote such an API for use by standard
audio applications, we will continue to waste people's time and make
great steps forward more difficult. 

In the world of TDM/VST/MAS etc., developers can focus on what
matters: using great algorithms, writing great code, designing great
(or at least good) user interfaces. They *never* have to write code
that deals with hardware-based concepts.

Right now, this explosion of HAL-inspired API's (OSS, ALSA, CSL, the
rest) continues to require that developers deal with sample formats,
sample rates, channel interleaving, buffer sizes, period/fragment
sizes, and so on and so forth.

I just find this very frustrating. There is a distinct class of
application that needs to deal with such things, but in looking over
Dave Phillips' sound+MIDI for linux pages, there are almost no
applications listed there that appear to me to be in this class.  Why
then are we focused on APIs that are designed around such
applications?

--p