16 Nov
2008
16 Nov
'08
8:07 a.m.
Fons Adriaensen wrote:
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
On Sun, Nov 16, 2008 at 02:22:16AM +0200, Hannu
Savolainen wrote:
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.
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 ?
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.