[LAD] ALSA doumentation

[Hannu Savolainen]

Fons Adriaensen wrote:
> On Sun, Nov 16, 2008 at 02:22:16AM +0200, Hannu Savolainen wrote:
>
>   
>> 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.
>>     
>
> The problem is that this also happens when it's not
> required, and that the change is permanent.
>
> Just imagine: someone at the other end of the building,
> or at the other end of Parma, accidentally disconnects
> the MADI signal I'm receiving from him for a second.
> The driver / card switches to its internal clock and
> does not switch back when the signal is restored. So
> it is now permanently misconfigured. And before you 
> say I'm dreaming: we *do* have optical links running
> all over the town, they *can* carry a MADI signal and
> they *will* be used to do that.
>
> Do you really expect me or someone else to sit watching
> your control panel all day ? Do you have another solution
> than an application watching the state of the card, and
> restoring it when necessary ?
>   
Which one of the applications should do this? There may be up to 32 
applications playing to individual stereo pairs of the MADI interface. 
The same is true with recording. They may be file players, 
samplers/synths, VoIP links, DAW applications or whatever. Should each 
of them have a timer callback that checks the sync source and turns it 
back to original if it has changed? How do you ensure that all 
applications push to the same direction? Or maybe you have this 
functionality in your  hypercharged allmighty application that spends 
all it's time in babysitting the hardware.

This kind of workarounds belong to the hardware/firmware or the driver. 
They should be clever enough to take the clock from their internal 
DDS/PLL while the external clock is absent.

If this problem is not handled in hardware/driver level then you can 
simply use a script that runs in background and does "ossmix syncsource 
MADI" once a second. The same can probably be done using ALSA's command 
line tools. There is no point in reinventing the wheel in many applications.
>> Why should any audio application be different?
>>     
>
> I have already told you twice before, and a third time
> above. So I'm not going to repeat this again. If you
> don't want to understand, which seems to be the case,
> I'm wasting my time. I *do* understand your arguments,
> but they just don't apply in this case - I'm not writing
> a desktop MP3 player. 
>   
And what might your application do?

I agree that there are cases where special purpose programs need to 
control the hardware directly. However applications that open /dev/dsp 
or /dev/midi must not try to go down to the hardware.

In the OSS model practicaly all hardware level controls are hidden 
behind the control panel interface. It is possible to implement special 
purpose control applications that use this interface.

For example a control application may monitor the sync locked status and 
measured sampling rate of an AES/EBU input. When sync goes on it 
launches a DSP application that creates the filter tables for this 
particular sampling rate. When somebody disconnects the input the 
control application ramps down the output level and kills the DSP 
program. When something else gets connected to the input the new 
sampling rate will be measured and then the DSP program gets launced 
again with proper parameters.

The DSP program doesn't know anything about this. It can be used with 
any sound card (say ICH). The control program doesn't know what the 
actual application does. It just knows how to monitor given input of 
specific sound card model and to insert -s<rate> to the command line 
when it starts the app. Both programs can be used alone, together with 
each other or even with some other programs.


Best regards,

Hannu