* Re: Re: MAN301 external clock issues (Re: [PATCH] ALSA: dice: add stream format parameters for Weiss devices)
2023-09-20 10:25 ` Fwd: Re: MAN301 external clock issues (Re: [PATCH] ALSA: dice: add stream format parameters for Weiss devices) Michele Perrone
@ 2023-09-24 2:16 ` Takashi Sakamoto
0 siblings, 0 replies; 2+ messages in thread
From: Takashi Sakamoto @ 2023-09-24 2:16 UTC (permalink / raw)
To: Michele Perrone; +Cc: Takashi Iwai, Rolf Anderegg, alsa-devel
Hi,
On Wed, Sep 20, 2023 at 12:25:07PM +0200, Michele Perrone wrote:
> Hi Takashi,
>
> On 19/09/23 16:09, Takashi Sakamoto wrote:
>
> 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.
>
> I'm able to do this from the kernel space, but I wouldn't know how to
> achieve this in the user-space without switching back and forth between
> internal and external clock source.
> Moreover, there seems to be no 'write' handler installed inside
> 'snd_dice_create_hwdep()'[2], so using 'snd_hwdep_write()' from
> user-space ALSA is not possible.
> The only option I see is adding a new control to
> 'snd_kcontrol_new controls[]'[3], inside 'dice_snd_ctl_construct()'[3]
> in our AV/C code.
> But I don't think this is the best solution, in view of the fact the we
> will be switching to snd-firewire-ctl-services[4] in the near future.
>
> 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.
>
> Thanks for explaining this. I have now found the place in the code
> where
> you do this[1].
> May I ask, what is the reason for this limitation? I don't see any
> relevant connection between that last used internal sampling rate, and
> the current external sampling rate.
> Moreover, the DICE driver is able to see the external sampling rate in
> real-time. So when the external clock rate is selected and locked,
> wouldn't it make sense that the device rate followed the external rate
> automatically, without user-space intervention?
In TCAT general protocol, we can find several fields for detected
sampling frequency[1].
* STATUS_NOMINAL_RATE_MASK (offset 0x54 in global section)
* GLOBAL_SAMPLE_RATE (offset 0x5c in global section)
* EXT_SYNC_RATE (offset 0x08 in external sync section)
The last two of them are extension or optional, thus we assume that all of
models with DICE ASICs do not necessarily support them. As long as I
investigate, the first is just for detected nominal sampling transfer
frequency in incoming IEC 61883-6 stream which is locked, against your
expectation.
When supporting all of models with DICE ASICs in market and firmware, it
is inevitable not to rely on the auto-detection you mentioned. Actually,
old version of firmware does not support GLOBAL_SAMPLE_RATE. Furthermore,
we have a few models which support external sync section.
Just for models provided by Weiss Engineering, additional kctl could be
one of solution as you mentioned, but it seems to be hard for upstreaming
due to the reason, sorry.
Well, in the protocol, the device can send notification to registered
offset of node ID for several purposes. You can see below events in the
driver code:
* NOTIFY_RX_CFG_CHG
* NOTIFY_TX_CFG_CHG
* NOTIFY_LOCK_CHG
* NOTIFY_CLOCK_ACCEPTED
* NOTIFY_EXT_STATUS
For your issue, observation of lock-change, clock-accepted, and ext-status
notifications is useful, I think. The ALSA HwDep character device added
by ALSA dice driver is mainly for the notification[2]. When receiving the
notification, the driver cache the message and allow the user space
application to read it.
I maintain libhitaki[3] for convenience to such user space application.
Hitaki.SndDice implements Hitaki.QuadletNotification::notified GObject
signal[4], which is emitted when reading the notification. The library
supports GObject Introspection[5] to provide language bindings such as
PyGObject[6] and gtk-rs/gir[7].
You can see rough Python 3 sample to print the notification[8].
[1] See 'sound/firewire/dice/dice-interface.h' in Linux kernel
[2] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/include/uapi/sound/firewire.h?id=82fbb4f7b476
[3] https://github.com/alsa-project/libhitaki
[4] https://alsa-project.github.io/gobject-introspection-docs/hitaki/class.SndDice.html
[5] https://gi.readthedocs.io/en/latest/
[6] https://pygobject.readthedocs.io/en/latest/
[7] https://gtk-rs.org/gir/book/
[8] https://gist.github.com/takaswie/673a7f83964f7986d3f1e4e9b86cde03
Regards
Takashi Sakamoto
^ permalink raw reply [flat|nested] 2+ messages in thread