Hi,
I've been fighting with some devices for the case where ALSA device is a
clock slave. I'm also working on some patches/quirks to make some of
these things work.
I have couple of questions in this domain I didn't find documented:
1) How is application supposed to use ALSA capture device when it
doesn't know the sampling rate? For example with ASIO on Windows
application sets sampling rate to 0 to indicate slave and then starts
the device and retrieves the rate using ASIOGetSampleRate(). There are
typically also reset request messages when the rate changes.
2) Some USB devices have indicator for lock status between set sampling
rate and detected input rate. One such device I have is Motu 8D (UAC2
device):
Simple mixer control 'Internal Clock Validity',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [on]
As long as the status is valid, I can set sampling rate to the same, or
something else. When the status becomes invalid due to rate mismatch,
ALSA fails to set any of the sampling rates, even correct one and
there's an error message in dmesg: "usb 3-14: clock source 1 is not
valid, cannot use". So the clock source cannot be made valid again by
changing sampling rate once it has become invalid, because it is
currently invalid...
3) What is the correct way to deal with clock slave device from both
driver and application perspective? So that application can retrieve the
current sampling rate, instead of setting one... UAC2 has provisions for
this, but this doesn't seem to be supported by the current driver. I
have also some hardware where I would like to do the same with I2S -
where clock generator is outside of the SoC and the SoC is just a slave
(for example S/PDIF or AES/EBU input to a SoC where clock is generated
from the input stream using PLL).
Best regards,
- Jussi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
