Re: [LAD] ALSA doumentation

Fons Adriaensen wrote:
> On Sun, Nov 16, 2008 at 12:24:38AM +0200, Hannu Savolainen wrote:
>
>
>> By making this kind of changes pretty much impossible we can prevent
>> programmers from doing stupid mistakes. Before ading this kind of stupid
>> workarounds
>> they will probably ask somebody to help them. In this way there
>> is a chance that somebody with better knowledge can stop them.
>>
>
> It seems like you missed the point: there can be good
> reasons for making this kind of changes from a program
> and not only interactively by using some control panel.
> It all depends on what the program is, and who is running
> it. Any normal app should probably not touch these settings,
> but a session manager that sets up a multi-PC studio should
> be able to do it. Even more so if most of the PCs involved
> are in a machine room that is normally not accessible by
> the studio's users.
>
> In my case, the sample clock source should always be 'external'
> (pretty obvious in a multi-machine setup), but the driver will
> change it permanently to 'internal' when the external signal is
> absent, which can happen temporarily. So I need not only set
> this when initialising a session, but watch it permanently and
> reset it when necessary. Since the users of this setup can't
> be bothered to understand such things, it has to be automatic
> and not by using some control panel.
>
Right. The driver or the hardware itself can do this transition
automatically when it's required. The control panel will reflect this
change in way or another.

However there is absolutely no idea in implementing this kind of
functionality in more than one application. The control panel program
shipped with the sound subsystem can do the change out of box. If a MP3
player (or whatever) implements support for this kind of control then
does it make the world better?

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. All audio applications have some kind of audio
stream to play/record (with given sample rate/format). This is all they
should care about. It's responsibility of the audio subsystem to ensure
that the stream is properly converted to match the capabilities of the
actual device. Applications can (optionally) check if the device
supports 192 kGz/32 bits/64 channels before giving the user a choice to
use such format. However in the OSS model they are not required (or
supposed) to do this. OSS will automatically do the conversions or to
return an error if the requested rate/format/#channels combination
doesn't make any sense with the current device.

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.
Why should any audio application be different?

Best regards,

Hannu

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Nov 16 04:15:01 2008