kernel issues with Schiit USB DAC (UAC2, high-speed Isochronous)

Troubleshooting
1

I believe that I am experiencing a kernel issue when using a Schiit Fulla 2 USB DAC / headphone amp. The DAC sounds great, but always freezes after rapidly skipping through tracks. Schiit themselves describe it as a Pi kernel issue. Suggestions? Details:

  • A very nice and informed person at Schiit said: “The issue as you’ve noted is indeed with Raspberry Pi where its USB implementation has a flaw with UAC2 USB devices. Not much we can do about it since UAC2 is the preferred standard for windows, mac, most desktop linux, etc. … Perhaps some future Linux kernel will fix the issue.”

  • A Pi Foundation github issue thread describes a perhaps related situation with a different Schiit DAC: “Both the reported problems are with a specific type of DAC. This DAC is unusual in being a high-speed device. There are differences with handling of packet intervals for high-speed Isochronous devices, which a move to 3.18 may have caused to change.” Alas, the solution on that thread did not fix my problem. https://github.com/raspberrypi/linux/issues/888

  • More on the problem: DietPi, VLC (vlc-nox), headless. I can always make the DAC freeze (stop playing audio) by rapidly skipping through tracks with VLC. I can cause the problem in 20 seconds. As far as I can tell, VLC still thinks it’s playing music. The DAC does not recover - have to reboot. The track skipping seems to be part of the equation - if I just let music play, the DAC seems to behave properly for quite a while.

  • I tried the usual cures: swapped cables, swapped Pis, swapped power supplies. The Fulla 2 can be externally powered, so I tried that. I swapped USB DACs - the non-Schitt DACS work correctly but don’t sound as good. I started with DietPi. But hit the same issue in Raspbian Lite even after rpi-update to get the most recent stable kernel.

Suggestions? I’m open to very experimental suggestions e.g. using new unstable kernels. I’m controlling vlc-nox via Python bindings, so I can run some code prior to each track skip, but I’m not a USB expert, so I wouldn’t know what action to take in code (USB device reset of some kind?).

Thanks,
Ross

2

rosswesleyporter
Many thanks for reporting.

The issue you linked should have been solved long time ago. But did you try with the latest larger kernel 4.19 update?
apt upgrade

3

Thanks for the reply!

Yes, running 4.19. Alas, the issue persists. Schiit (DAC manufacturer) was very clear in saying that there are UAC2 issues on Pis specifically, but not on “desktop Linux”. The person at Schiit that said this seemed well informed.

Do you think that upgrading to a mainline kernel (e.g. 5.1) would help? I’m happy to try that and report back. If so, I’d be grateful for a link on how to build a mainline kernel on a Pi 3B+ as I don’t have a desktop Linux system for the cross-compile.

Alternatively, I could try with a different SBC e.g. a NanoPi M1 or an ODroing-XU4. I only have Pis at the moment, but I could order one of those boards.

Thanks,
Ross

4

Okay I also found very rare but unsolved search results about Zoom UAC2 on RPi. Yeah it seems to be simply not possible currently :frowning:.

With mainline kernel you will break many other features and will most likely not fix this one. There is a reason why on Raspberry Pi there is a large team working on new kernels. The hardware requires much customisation to work, until this is (very slowly) integrated into mainline. If it was that easy, other manufacturers would update their kernel packages as well, but in reality this is muuuch to much work for small manufacturers so they stick with a single kernel version which is never updated usually :wink:.

With “desktop Linux” the guy from Schiit most likely means x86 systems. Things there are usually ALOT easier then on ARM, especially also since affected systems and devs are a lot more etc.

So it’s up to the UAC2 manufactures to contact RPi devs to get this integrated into their kernel. Some other DACs that required a custom kernel module/overalay build prior, has been integrated with v4.19, so there is no freeze about this.

You could ask the guy btw if there is any way to build a device tree overlay or kernel module from source on ARM systems, for some other DACs it was.

5

Thanks for the definitive response. That lets me move on to other projects. Maybe I’ll come back to this one when the Pi Foundation moves to a 5.x kernel.

6

rosswesleyporter
Did you get some info that 5.X mainline kernel has integrated support for UAC2?
Changelogs: https://kernelnewbies.org/LinuxChanges/

Otherwise note that 4.20 => 5.0 was not a special step or such. The major version integer was only raised to make Torvalds happy, not because there were any more/deeper changes than usual :smiley:.

7

I don’t have any special info about additional UAC2 support in the 5.X kernel. Just uninformed hope. From what I read, even UAC3 support was baked into 4.19 mainline.

8

rosswesleyporter
I am also no expert in this. Possibly also even if the mainline kernel has support/drivers integrated, it does not work with RPi hardware due to other differences/limitations.

To get some more clarification from RPi dev side, or even push development in this topic a bid, you might want to open an issue on their kernel/firmware GitHub page: https://github.com/raspberrypi/firmware/issues
Perhaps UAC2 is not the issue but indeed some specific DACs (Schiit, ZOOM, …). Then most likely, if the drivers are open source, a custom build would be possible. If UAC2 itself is the issue, then most likely not :thinking:.