[LAD] ALSA doumentation
Hannu Savolainen
hannu at opensound.com
Sun Nov 16 21:16:19 UTC 2008
Fred Gleason kirjoitti:
> 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.
>
>
>
Programmers are not stupid. However the way how typical sound
applications are implemented is wrong.
>> 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.
>
Network or disk performance analyzers/monitors/optimizers are good
tools. They are not "ordinary" applications but system tools. However
it's wrong if programs like Mozilla try to do this kind of functions.
All a web browser does is opening a TCP/IP socket to the
http/ftp/whatever server, sends the request and waits for the response.
Equally well an audio player application should just open a connection
to the audio device, set the rate/format and then just start to play.
They should not try to do things like automatic unmuting the sound card.
> 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.
>
I would not call it as "making hard things impossible". The idea is to
make programmers to think twice before they start doing stupid mistakes.
Best regards,
Hannu
More information about the Linux-audio-dev
mailing list