Mytek Stereo192-DSD-DAC crackling since duplex stream synchronisation removal CIP_SYNC_TO_DEVICE in 2016 about linux-firewire-dkms

[takaswie]

@vermeeren

This is the exact behaviour change noted for Stereo 192-DSD-DAC, even though
it is Dice Mini (TCD2210) per firmware research you did in 2018[4]. With old
modules playback did almost always not work the first time at a new sampling
rate, but when it plays audio the second time the lock is perfect and playback
is good. With new modules playback always works first time, but also always
with crackling.

Another negative side of the implementation for CIP_SYNC_TO_DEVICE is to
handle one 1394 OHCI isochronous transmit (IT) context (=PCM playback direction)
in IRQ handler for one 1394 OHCI isochronous receive (IR) context (=PCM capture
direction). The implementation aims to reuse information in the packet for IR
context for packet IT context; e.g. the number of PCM frames in packet,
timestamp of the packet.

However, DICE ASICs can support two pairs of isochronous packet streams as maximum
for each direction. The implementation can't support all of models based on DICE
ASICs. For example, models by Focusrite supports:

name	num. of isoc. streams for capture direction	num. of isoc. streams for playback direction
Saffire Pro 14	1	1
Saffire Pro 24	1	1
Saffire Pro 24 DSP	1	1
Saffire Pro 26	2	1 (yes...)
Saffire Pro 40	2	2
Liquid Saffire 56	2	2

Furthermore, when the target device skips some isochronous cycle to transfer
packets, hardware IRQ of 1394 OHCI controller for IR context is postponed. As
a result, the implementation of CIP_SYNC_TO_DEVICE can not keep constant
throughput for IT context. the sequence of IR packets has the lack of
information to process packets for IT context every isochronous cycle. Although
the lack of information should be complemented to process packets in IT
context, the implementation of CIP_SYNC_TO_DEVICE has no mechanism for
the above. OXFW and Fireface are the kind of device and the implementation
brings troubles to them.

For the above reasons, the implementation was dropped.

Although I am somewhat familiar with concepts because of research to determine
the issue, I am not familiar enough to re-implement duplex stream
synchronisation in modern ALSA firewire driver. I also cannot determine the
real problem very well, it could be duplex stream synchronisation was masking
the real bug in either device or ALSA firewire driver.

The main of underlying issue is that some models (and yours) require software
driver to replay the sequence of packets for IT context in a point of the number
of PCM frames per packet, but IEC 61883-1/6 packet stream engine in ALSA
firewire stack doesn't. The engine still use pre-computed table to process
packets in IT context. Although the table gives throughput exactly the same as
sampling frequency for the number of PCM frames per packet, it is not suitable
to the models. The next underlying issue is timestamp per packet.

Between 2019 and 2020, I've implemented 'AMDTP domain'[1][2]. The concept is:

• process several IR/IT context in one hardware IRQ handler
• the handler runs for IT context (=irq_target) for constant throughput

My work for it is still in intermediate. I have a plan to integrate it for:

• one of the IR contexts is selected as the context in which timing
  information is reused to process for the others (not implemented yet)
• during no packet in IR context is available, process packets for IT context
  with pre-computed timing information. (not implemented yet)

Currently, the timing information for IT context is still based on pre-computed
table which implemented in the beginning of ALSA firewire stack[3] therefore
some models still generate sound with crackling noise.

In my plan, I use this spring and summer for the above tasks.
I expect it will be tough work since ALSA firewire stack supports different 8
types of devices. The sequence of packet for the types are different each other.

(our work look to regain the items from land of that which is forgotten.)

[1]https://mailman.alsa-project.org/pipermail/alsa-devel/2019-August/153388.html
[2]https://mailman.alsa-project.org/pipermail/alsa-devel/2020-May/167447.html
[3]https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=31ef9134eb52

[takaswie]

@vermeeren Anyway I respect your work to bisect patches and find the positive side of CIP_SYNC_TO_DEVICE. I apologize not to give enough information in advance.

[vermeeren]

@takaswie Thanks a lot for the detailed reply, I appreciate it. No worries about a lack of information at all.

I have done some reading in the other issues which I think is effectively the same problem as with this DAC, I see there is a design task at hand with the comment in #26 (comment). If I understand correctly, the problem is dynamic runtime determination of SYT interval?

Really I only have some crude, basic ideas for this, as I don't know enough of the technical side so perhaps there are hardware constraints. But abstractly speaking, would something like that be suitable? Assuming inbound packets from device is always device's clock.

1. Start streaming at pre-computed table rate.
2. Count number of inbound packets for some interval, perhaps some milliseconds or a second?
3. Calculate packets/second or similar with above information and set SYT interval based upon newly calculated value.
4. Reset counter, go to 2.
   • Alternatively, further refine calculations using the average of the past X intervals instead of only the latest. Probably over-engineering.

With this type of approach, sound may only have crackling the first counter interval period, which is not really a problem in practice as this type of device is used for long playback/recording session typically with Jack or perhaps ALSA directly.

Edit: I now realise this is most likely the exact same idea you proposed in earlier comment, it sounds good to me!

---

Unrelated: I have confirmed that there is a incredibly small chance that DAC works properly with new driver on stream start. I feel like the chance for this is a 5% at best. Presumably this is when you are lucky and the pre-computed table matches exactly the signal lock. If it does work like this, it will work the entire lock duration perfectly for many hours.

[vermeeren]

@takaswie By the way, I recall the Windows driver for this device takes multiple real seconds when changing the lock. I suppose their approach is to forbid any playback/capture from userspace until the timing has stabilised which takes those few seconds. For ALSA I think such an additional forced delay has more negatives than positives, as the timing will stabilise very quickly once streams are started.

Also, feel free to CC me in any relevant devel mails, if it would help for me to do some hacking or patch reviewing I'd be glad to do so too.

[takaswie]

@vermeeren As another topic, I'm currently working for systemd to support hardware database for units in IEEE 1394[1]. I mostly generate these entries from my collection of images for configuration rom, retrieved from actual devices. I realized to have no image of your Mytek Stereo192-DSD-DAC. Would I request you to make image file and send it to me, or MR to my repository?

[1] systemd/systemd#19124
[2] https://github.com/takaswie/am-config-roms/

Thanks

[vermeeren]

@takaswie Yes of course I can do that, I tried reading a bit but cannot find how to make such an image. Could you tell me how to do it?

[takaswie]

@vermeeren

Yes of course I can do that, I tried reading a bit but cannot find how to make such an image. Could you tell me how to do it?

Sorry to request without any instruction...

Linux kernel has sysfs to export attributes of kobjects, which represent any instance maintained in kernel space. Linux FireWire subsystem maintains nodes and units in IEEE 1394 bus as kobject, and adds an attribute for content of configuration ROM into the kobject corresponding to the node.

When your Mytek Stereo192-DSD DAC is detected as fw1, the image can be created by:

$ cat /sys/bus/firewire/devices/fw1/config_rom > mytek-stereo192-dsd.img

Cherrs

[vermeeren]

@takaswie I have created MR to your repository, see takaswie/am-config-roms#2. Thanks!

[takaswie]

Hi @vermeeren ,

Just now I pushed patches to topic/media-clock-recovery remote branch (f3bdd2c).
Would I ask you to test it with your device?

With this patchset, ALSA IEC 61883-1/6 packet streaming engine processes incoming and
outgoing packets by:

1. Transfer outgoing packet with pre-computed table rate in its beginning.
2. Pool presentation timestamp in incoming packets after starting receiving them
3. Then transfer outgoing packet by media clock recovered from the presentation timestamp

In a prompt test, it looks well with TC Electronic Konnekt 24d at 44.1/48.0 kHz. I wish it also
works well in your device.

Cheers.

[vermeeren]

Hi @takaswie

Had some time today to review and test patches. I did testing with Debian bullseye kernel 5.10.28 and can confirm it works perfectly. Tried various settings, period/buffer size and frequencies, the lock always works in one go and there are no pops or other problems in audio signal. Patches themselves I read too and it all looks very good to me.

I also tested combination with Saffire Pro 24, which worked before, and this unit still works perfectly, so no change there. We can conclude it fully fixes problem for Stereo 192-DSD DAC and presumably all Dice-based audio interfaces requiring clock recovery.

Thanks a lot for your work, I really appreciate it! Feel free to let me know if you need help with something in the future, I'll gladly take a look.

[takaswie]

Hi @vermeeren ,

Thanks for your test, and it's nice to work well in your side, too.

Although I still find some issues in the other devices (e.g. TC Electronic Studio Konnekt 48, Alesis iO 26 and iO 14, Focusrite Saffire Pro 40, Focusrite Liquid Saffire 56), it's a good start to improve ALSA IEC 61883-1/6 packet streaming engine against the long-standing problem.

The patchset is still a skeleton since it doesn't include any check against unexpected situation (e.g. the incoming packets from device is discontinued) and I continue to work this week. Later I will contact to you for further testing. Additionally, I will post to mailing lists (e.g. LAD) for further testing. Anyway I'm glad to get your cooperation again.

Cheers.

[vermeeren]

@takaswie Yeah I noticed today that if a discontinuity occurs it appears to hang, freezing the userspace process holding the ALSA device also. With the old driver from 2016 on discontinuity with DAC the DAC would lose audio playback (Saffire Pro24 would still work) but packet streaming would continue, requiring restart of Jack in practice. With current patchset SIGKILL to Jack and restart Jack makes it work again.

Having a recovery mechanism for packet discontinuity would be very nice, I await with anticipation!

[takaswie]

Hi @vermeeren ,

Having a recovery mechanism for packet discontinuity would be very nice, I await with anticipation!

I implement it and move HEAD of topic/media-clock-recovery remote branch into 86a686e d54ba5d.
Would I request you to test it with your devices?

In this trial, I implements:

• cycle discontinuity check and let applications recover ALSA PCM substream by receiving XRUN state
• transfer isoc packets to device at the same timing even if they are transferred by several IT context
  • for dualwire function of DICE ASICs

Especially, I'm successful at last to get clear sound from below models at 44.1/48.0 kHz:

• Focusrite Saffire Pro 40 (supporting two pairs of isoc streams)
• Focusrite Liquid Saffire 56 (supporting two pairs of isoc streams)
• TC Electronic Studio Konnekt 48 (supporting two pairs of isoc streams)

However, I still found some troubles at higher sampling transfer frequency.
If you attempt to test at higher sampling rate, I'm appreciate to receive your report as well.

Thanks

[vermeeren]

Hi @takaswie,

Today I review new patches and test them with Stereo 192-DSD DAC. The XRUN handling appears to work nicely, as intentionally causing XRUN Jack reports it as expected but the stream recovers and keeps playing audio successfully.

About sampling rate, that is actually unexpected. Even with the previous patchset 192kHz S32_LE playback worked correctly on Stereo 192-DSD DAC, I think I also tried 176.4kHz which also worked fine. Current patchset also handles it nicely, I don't notice any changes here. However from formation file:

Output stream from unit:
        low     middle  high    MIDI
Tx 0:   8       8       8       0
Tx 1:   0       0       0       0
Input stream to unit:
        low     middle  high
Rx 0:   4       4       4       0
Rx 1:   0       0       0       0

If I understand correctly, Stereo 192-DSD DAC only uses a single pair of isoc streams even for 192kHz sampling frequency, so presumably that is why high sampling rate works correctly on this unit.

As for Focusrite Saffire Pro 24, it works well like with previous patches. This device has maximum 96kHz sampling frequency and I think also a single pair of isoc streams. The formation for this unit:

Output stream from unit:
	low	middle	high	MIDI
Tx 0:	16	12	0	1
Tx 1:	0	0	0	0
Input stream to unit:
	low	middle	high
Rx 0:	8	8	0	1
Rx 1:	0	0	0	0

Note that from userspace point of view I always open DAC in playback-only direction mode and Saffire in bidirectional mode, but I do not think this matters for kernel driver.

---

Unrelated to the above, sometimes I cannot open streams and following shows up in kernel ring buffer:

snd_dice fw2.0: isochronous resources exhausted

It always happens after turning on/off a device, never while they are on even for hours. Sometimes I can fix this by power cycling DAC and/or Saffire, but sometimes I feel like a reboot is needed to correct this problem, not sure. Is this an issue you are familiar with? It could be an issue with firewire_ohci too maybe?

Cheers.

[takaswie]

About sampling rate, that is actually unexpected. Even with the previous patchset 192kHz S32_LE playback worked correctly on Stereo 192-DSD DAC, I think I also tried 176.4kHz which also worked fine. Current patchset also handles it nicely, I don't notice any changes here. However from formation file:

Hm. You mean your device was not under locked state at 192.0 kHz?

Note that from userspace point of view I always open DAC in playback-only direction mode and Saffire in bidirectional mode, but I do not think this matters for kernel driver.

Yep.

Unrelated to the above, sometimes I cannot open streams and following shows up in kernel ring buffer:

snd_dice fw2.0: isochronous resources exhausted

It always happens after turning on/off a device, never while they are on even for hours. Sometimes I can fix this by power cycling DAC and/or Saffire, but sometimes I feel like a reboot is needed to correct this problem, not sure. Is this an issue you are familiar with? It could be an issue with firewire_ohci too maybe?

Thanks for the report. The issue seems to come from bugs in current implementation of ALSA dice driver. I'll investigate further later.

The message mean that all of available isochronous context in 1394 OHCI controller under used are reserved. In IEEE 1394, when using isochronous communication, any node should reserve isochronous resources such as channel and bandwidth, maintained by isochronous resource manager (=typically 1394 OHCI controller).

[vermeeren]

Hm. You mean your device was not under locked state at 192.0 kHz?

@takaswie I mean the device (Stereo 192-DSD DAC) locks properly at 192kHz and playback works perfectly, both with current topic/media-clock-recovery and the previous version from #34 (comment).

So it is a bit strange that on the devices you test in #34 (comment) there are troubles with higher sampling frequency. At a glance the difference is that my device has only one pair of isoc streams, but yours have two pairs?

Cheers.

[takaswie]

I mean the device (Stereo 192-DSD DAC) locks properly at 192kHz and playback works perfectly, both with current topic/media-clock-recovery and the previous version from #34 (comment).

Now I got it. Thanks for your indication.

So it is a bit strange that on the devices you test in #34 (comment) there are troubles with higher sampling frequency. At a glance the difference is that my device has only one pair of isoc streams, but yours have two pairs?

At present, I think so. The mechanism for device to process PCM frames in received packets has difference somehow between with one pair and two pairs. I have some hypothesis that they require received packets at the same isoc cycle with the same SYT value, and they require received packets with sequence replayed from transferred packets at the beginning of the packet streaming already. I'm currently working for the hypothesis.

Thanks

[takaswie]

I note that patchset for the issue is posted to upstream:

• https://lore.kernel.org/alsa-devel/[email protected]/

[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.

[vermeeren]

@takaswie I have updated modules with DKMS some time ago and it has been working fantastically the past week or two, thank you a lot for the work! Happy to see it merged upstream.