SYT field being always zero does not mean sync cannot be done

[zamaudio]

This statement is not quite correct: https://github.com/takaswie/snd-firewire-improve/blob/618f4f4e2e6e27585820b2f9f873171b8bd5e758/sound/firewire/digi00x/digi00x-stream.c#L332

There is an implementation of Amdtp streaming specifically for Oxford chips that have SYT field in transmitted packets always = 0x0000 that uses system timestamps of packets instead of the SYT value and adjusts on the fly with a DLL. See the source code of ffado: http://www.ffado.org/files/libffado-2.3.0.tgz

I think it would improve the digi00x driver.

[takaswie]

Hi Damien,

The whole comment is:

/*

• The value of SYT field in transmitted packets is always 0x0000. Thus,
• duplex streams with timestamp synchronization cannot be built. */

In a case that SYT field includes no information, we cannot recover sampling clock in a way described in IEC 61883-1/6. You can see simple diagram for this mechanism in clause 4.3 Packetization layer of Audio and Music Data Transmission Protocol 2.2 Revision 1.1 (Oct. 2010, 1394 Trading Association, Document 2009013). This is my intention for this comment.

However, IEC 61883-1/6 is a kind of protocol adhered to isochronous cycle. In IEEE 1394 bus, it's 8,000 cycles per sec. With this cycle and the accumulated number of events in received packets, the receivers can recover sampling clock without the sequence of SYT field. This is the way that FFADO userspace library implements for some of OXFW970/971 based devices.

As you noted, it's probable to improve current ALSA IEC 61883-1/6 packet streaming engine for ALSA firewire-digi00x driver with the above idea. At present, the engine is designed to transfer PCM frames as exactly the same as sampling frequency; e.g. 48.0kHz. However, as long as I investigated, the target devices in Digidesign Digi00x family is not designed to handle PCM frames as the frequency, at least on isochronous packets on IEEE 1394 bus.

For example, this is a sample of sequence of isochronous packet from the device at 48.0kHz sampling transfer frequency (stf) in blocking transmission method:

total sec cycle
48000 0 71
48000 1 71
47992 2 71
48000 3 71
48000 4 71
48000 5 71
48000 6 71
47992 7 71
48000 0 71
48000 1 71
48000 2 71
47992 3 71
48000 4 71
48000 5 71
48000 6 71
47992 7 71
48000 0 71
48000 1 71
48000 2 71
48000 3 71
47992 4 71
48000 5 71
48000 6 71
48000 7 71

I can see the device does not transfer events as the same as stf once per several cycles. At the same time, Windows driver transfer events on isochronous packet in non-blocking transmission method:

total sec cycle
47998 0 71
47999 1 71
47998 2 71
47998 3 71
47998 4 71
47998 5 71
47998 6 71
47999 7 71
47998 0 71
47998 1 71
47998 2 71
47998 3 71
47999 4 71
47998 5 71
47998 6 71
47998 7 71
47998 0 71
47999 1 71
47998 2 71
47998 3 71
47998 4 71
47998 5 71
47999 6 71
47998 7 71

I can see the Windows driver neither transfer events as the same as stf nor the sequence of received isochronous packets from the device. This comes from application of different transmission method to both packet streams.

Anyway, it's clear that current strategy of ALSA IEC 61883-1/6 packet streaming engine is not necessarily suitable for protocol of DIgidesign digi00x family. Furthermore, porting from FFADO implementation is not suitable as well. The phase detection should be ranged for several seconds to generate the sequence of event number from received packets for transferred packet.

[zamaudio]

@takaswie the approach we could use that FFADO also uses, is to convert non-blocking transmission into blocking so we can use your existing blocking streaming system: Collect the frames that appear on the bus into a pseudo-packet buffer. Once 1x SYT_INTERVAL of frames is present, mark the packet as being present, measure the time of arrival of this packet and use that as a timestamp.

[takaswie]

I attempt to implement media clock recovery. If still interested, please test current HEAD of topic/media-clock-recovery remote branch (3a2c5fd52657).

[zamaudio]

I no longer have the hardware, but I heard a report that it now works!

[takaswie]

I note that patchset is posted to upstream:

• https://lore.kernel.org/alsa-devel/20210531025103.17880-1-o-takashi@sakamocchi.jp/

[takaswie]

The patchset is merged to upstream. The patches are also available in master branch of the repository. Let me close the issue. Thanks for your cooperation.

[takaswie]

P.S. The service program to control the device is available. Please refer to below URL if you are interested:

• https://github.com/alsa-project/snd-firewire-ctl-services/