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
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Reply via email to