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