Re: MAN301 external clock issues (Re: [PATCH] ALSA: dice: add stream format parameters for Weiss devices)

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

Hi Michele,

On Mon, Sep 18, 2023 at 03:19:10PM +0200, Michele Perrone wrote:
> Hi Takashi,
> 
> I'm encountering a strange issue when working with our MAN301 device and
> external clock sync. I am currently using our kernel-side AV/C code to
> switch between clock sources[1].
> 
> When I switch to an external clock source, the user-space ALSA code is not
> able to change the clock rate anymore. This means that I cannot switch to
> the external clock rate that the DICE is currently locked onto.
> 
> Here is a practical example / steps to reproduce:
> 
> 1. Set the clock source to internal and the clock rate to an arbitrary
>    value (e.g. 44100) from the user-space. The relevant sections of
>    /proc/asound/card0/firewire/dice will then look like this:
> 
> global:
>   owner: ffc0:000100000000
>   notification: 00000040
>   nick name: Weiss MAN301
>   clock select: internal 44100
>   enable: 0
>   status: locked 44100
>   ext status: 00010001
>   sample rate: 44100
>   version: 1.0.12.0
>   clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc
> internal
>   clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF
> (TOS)\Unused\Unused\Unused\Unused\Word Clock
> (BNC)\Unused\Unused\Unused\Unused\Internal\\
> 
> ext status:
>   clock source: internal
>   locked: 1
>   rate: 44100
> 
> 2. Set the clock source to external (e.g. aes1) through AV/C command[1]
>    and connect a digital input with a different clock rate (e.g. 48000).
>    Now the two sections of will look like this. You can see that the
>    external source status is "locked".
> 
> global:
>   owner: ffc0:000100000000
>   notification: 00000010
>   nick name: Weiss MAN301
>   clock select: aes1 44100
>   enable: 0
>   status: unlocked 44100
>   ext status: 00010001
>   sample rate: 44100
>   version: 1.0.12.0
>   clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc
> internal
>   clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF
> (TOS)\Unused\Unused\Unused\Unused\Word Clock
> (BNC)\Unused\Unused\Unused\Unused\Internal\\
> 
> ext status:
>   clock source: aes1
>   locked: 1
>   rate: 48000
> 
> 3. Try to set the clock rate to 48000 from user-space ALSA. This will
>    fail. Only 44100 can be used. Example:
> 
> $ aplay --disable-resample 48000_S32.wav
> Playing WAVE '48000_S32.wav' : Signed 32 bit Little Endian, Rate 48000 Hz,
> Stereo
> Warning: rate is not accurate (requested = 48000Hz, got = 44100Hz)
> 
> 
> The current workaround is going back to the internal clock source, switch
> the clock rate to the one reported in the "ext status" section, and then
> go back to the external clock source. This however does not feel quite
> right.
> 
> I will be very grateful for any suggestion from your side.
 
I programmed ALSA dice driver to behave like that.

The driver configures the target device for sampling rate which ALSA PCM
application expects when the device uses internal source of clock. When
the device is configured to use external source of clock, the driver
adds constrains to ALSA PCM hardware configuration so that the application
works with current sampling rate configured in device.

In your case:

clk src    ext rate   rate in device   appl avail rates
--------- ---------- ---------------- ------------------
Internal       -         44.1 KHz        44.1-192.0 kHz
External    48.0 kHz     44.1 kHz        44.1 kHz

For the case of external source of clock, you need to configure the
sampling rate in device by your hand, by accesing to GLOBAL_CLOCK_SELECT
offset in global section of TCAT protocol.

As a result:

clk src    ext rate   rate in device   appl avail rates
--------- ---------- ---------------- ------------------
Internal       -         44.1 KHz        44.1-192.0 kHz
External    48.0 kHz     48.0 kHz (*)    48.0 kHz

I note that the device's behaviour of the external source scenario
differs depending on models even if the pair of models uses the same
Dice ASIC. I guess that firmware version brings such chaos.

> Thank you and kind regards,
> Michele Perrone
> 
> [1]https://github.com/weiss-engineering/snd-dice/blob/5a95496c0666048bc5bc8c07b3e1d74f392dc9a4/dice-avc.c#L436


Regards

Takashi Sakamoto