[LAD] ALSA doumentation

[Jack O'Quin]

On Sat, Nov 15, 2008 at 7:37 PM, Fred Gleason <fredg at paravelsystems.com> wrote:
> On Saturday 15 November 2008 07:22:16 pm Hannu Savolainen wrote:
>> ALSA's design philosophy has been to expose all aspects of the sound
>> hardware to the applications so that they can play with any of them.
>> This is all bullshit.
>
> So the solution is to say "stupid application programmers, they can't be
> expected to know any better", and then hardwire logic into the driver system
> to force it to use the behavior appropriate for an MP3 player?  I'm not sure
> that this is a smart design tradeoff.
>
>
>> If you look at any kernel level subsystem such as networking or access
>> to ordinary disk files. None of such applications want to know anything
>> about the actual hardware details. I have not seen any PHP or CGI
>> scripts/programs that try to switch the NIC card to use 1 gigabit
>> signalling rate instead of the 10 mbit one supported by the network HUB.
>
> Actually, I can think of cases where something like that could be extremely
> useful -- a network analyzer or monitor, for example.  It's not a common
> requirement (just as altering the sample clock sync source is not a common
> requirement for most audio apps), but absolutely needed for some problem
> domains.
>
> One of the nice things about the Un*x design paradigm is how the goal is
> consistently been "to make simple things easy, and hard things possible".
> Unfortunately, in the world of audio APIs, it seems that we've fallen between
> two stools: we have one API that makes simple things easy, but hard things
> *impossible*, and another that makes *everything* possible, but also hard.
>
> How do we bring these two worlds together?

Use a layered approach.  Most applications should use some simpler
interface like JACK or PulseAudio.  The low-level driver interface
should expose the full capabilities of the audio hardware for more
complex control purposes.
-- 
 joq