Welcome to part 2 of my guide. To see part 1 visit:
https://lovelybabylon.noblogs.org/comprehensive-guide-how-to-use-mackie-onyx-1640i-with-debian-linux-on-lenovo-thinkpad-t420-with-near-0-xruns-at-48khz-with-around-20-322ms-total-roundtrip-latency-part-1/
Since I still experienced XRUNS in the long run even when using playback only. I continued to wiggle around with different kernels and the latest kernel that I tried was v5.12-rc3 that could apply mentioned in the previous parts FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller (rev 04) patch. You can find already patched source code [here] and used config [here]. I am sure the patch doesn’t apply nicely to kernels v5.13+ but someone could try to adapt it by hand.
Following the fact I am recompiling the kernel I used some other useful setting from ALSA-Project Wiki. Mentioned here [XRUN_Debug]. So I enabled the necessary kernel build options:
areyouloco@studio:~/code/linux$ grep \
-e "CONFIG_SND_PCM_XRUN_DEBUG" \
-e "CONFIG_SND_VERBOSE_PROCFS" \
-e "CONFIG_SND_DEBUG" .config
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_VERBOSE=y
CONFIG_SND_PCM_XRUN_DEBUG=y
If you use tools like make menuconfig/make xconfig that options are in: Device Drivers —> Sound card support —> Advanced Linux Sound Architecture —> Debug
In order to use that kernel debugging options I am going to enable it by using second option. It should be enough:
# Enable basic debugging and dump stack, check hardware pointer on the period update
# Usefull to just see, if PCM stream is stopped for a reason (usually wrong audio process timing from scheduler)
# And to check the values from driver
areyouloco@studio:~/code/linux$ sudo echo 11 > /proc/asound/card2/pcm0p/xrun_debug
In my case it was card2. You can check it out by running:
areyouloco@studio:~/code/linux$ cat /proc/asound/cards
I also uploaded new kernel version 5.12.0-rc3-rt3-fw-00003-g608d0b4b4952 that is the last one I’ve tried that supported Ricoh FireWire patch, RT patch and tweaks from above.
So I manged to get debug info about that XRUN that makes the JACK process hang. Here is more detailed bug report.
[…]
Still hunting that long playback hang…