jackaudio
Using a B550 Motherboard results in using only 96000 without xruns
Describe the bug
I'm using Cadence and whenever I try to use Jack audio, I'm unable to use any other sample rate besides 96000. Everything results in xruns except 96000.
Environment
- JACK Version: jackdmp version 1.9.19 tmpdir /dev/shm protocol 9
- Operating System: Arch Linux
- Installation: Using pacman
Steps To Reproduce
Use Jack audio on a B550 motherboard. Install everything correctly (on an Arch system).
Expected vs. actual behavior
I can't use any sample rate except 96000. Otherwise, I will have Xruns.
Here's Cadence/Jack logs: https://clbin.com/cB7hT
Have you tried using qjackctl? I'm experiencing similar behavior where to get Cadence to work reasonably I have to set 88200 or 96000 sample rates. Unfortunately, the performance was just barely bad enough to be unacceptable. I was trying to figure out where to submit a bug report until I found this bug.
However, using settings more similar to recommendations with qjackctl, jack works much much better. ~/.jackdrc contains /usr/bin/jackd -dalsa -dhw:Device -r48000 -p64 -n3 -P -zt . These settings are much more aggressive and work better than Cadence.
Symptoms
When using Cadence to start the jack server, the sample rate and buffer size must be set much higher to prevent xruns. Audio works acceptably except for the following. Every 3-9 minutes, a jitter (a high frequency clicking) occurs for 3-10 seconds, and suddenly clears and dmesg prints retire_capture_urb: XX callbacks suppressed and sound continues to play normally for 3-9 minutes again.
The clicks/jitter varies in perceptibility. If I plug headphones into the headphone output of the 5-channel speaker set connected to the 5-channel output of the motherboard, then it can be barely noticeable. Connecting headphones to a DAC with both USB and optical s/pdif inputs results in very noticeable clicks as described.
Dmesg output
[ +0.000008] audit: type=2501 audit(1637535397.969:2697): pid=392425 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='virt=kvm resrc=evdev reason=start vm="win10_passthroughUEFI" uuid=XXXXX path=/dev/input/by-id/usb-Logitech_G203_Prodigy_Gaming_Mouse_197038783830-event-mouse exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success'
[ +12.666761] retire_capture_urb: 4 callbacks suppressed
[Nov21 17:58] retire_capture_urb: 46 callbacks suppressed
[Nov21 17:59] retire_capture_urb: 22 callbacks suppressed
[Nov21 18:01] retire_capture_urb: 30 callbacks suppressed
[Nov21 18:03] retire_capture_urb: 46 callbacks suppressed
[Nov21 18:05] retire_capture_urb: 6 callbacks suppressed
[Nov21 18:09] retire_capture_urb: 14 callbacks suppressed
[Nov21 18:15] retire_capture_urb: 14 callbacks suppressed
[Nov21 18:20] retire_capture_urb: 14 callbacks suppressed
[Nov21 18:22] retire_capture_urb: 14 callbacks suppressed
[Nov21 18:23] retire_capture_urb: 14 callbacks suppressed
[Nov21 18:26] retire_capture_urb: 6 callbacks suppressed
[Nov21 18:27] retire_capture_urb: 6 callbacks suppressed
[Nov21 19:13] kauditd_printk_skb: 46 callbacks suppressed
Environment
- JACK Version: jackdmp version 1.9.19 tmpdir /dev/shm protocol 9
- Operating System: Manjaro 21.2.0
- Kernel:
Linux 5.15.2-2-MANJARO #1 SMP PREEMPT Sat Nov 13 19:25:38 UTC 2021 x86_64 GNU/Linux - Installation: package manager, Version: 1.9.19-2, Build Date: Mon 26 Jul 2021 01:15:38 PM EDT
- System: Asus x570 tuf gaming wi-fi with realtek alcs1200A, alsamixer 1.2.5.1-1, Yamaha Corporation Steinberg UR22mkII USB, Schiit Audio USB Modi Device
Notes
When starting jack with Cadence, the jackdbus binary changes status from stopped to started, as reported by jack_control status. Sound playback has glitches every 3-9 minutes as described.
When starting jack with qjackctl, a new process is started called jackd. Because jackd works great, I suspect that the problem is located in jackdbus, Cadence, or some dbus bug.
Had the same problem with that board. fwiw alsa_timer and clockperf are your friends. The clocks on some hardware are very bad.
Connecting headphones to a DAC with both USB and optical s/pdif inputs results in very noticeable clicks as described.
I'd expect more latency there given it's from USB. alsa_timer is a good test in cases like that. Where you're plugged into also matters.
FWIW x2 even hpet on some hardware is horrible (early ryzen/threadrippers for example). At least on linux.
Intel i5-4690K , F3-2400C10-8GTX DDR3 @ stock
== Reported Clock Frequencies ==
tsc 3500MHz
realtime 1000MHz
realtime_crs 1000Hz
monotonic 1000MHz
monotonic_crs 1000Hz
monotonic_raw 1000MHz
boottime 1000MHz
process 1000MHz
thread 1000MHz
clock 1000KHz
time 1Hz
== Clock Behavior Tests ==
Name Cost(ns) +/- Resol Mono Fail Warp Stal Regr
tsc 6.87 0.13% ---- Yes 0 0 0 0
gettimeofday 14.84 0.02% 1000KHz No 0 0 100 0
realtime 13.86 0.08% ---- Yes 0 0 0 0
realtime_crs 6.73 0.02% 1000Hz No 998 0 1 0
6.67 13.44%
monotonic 17.86 0.09% ---- Yes 0 0 0 0
monotonic_crs 6.73 0.02% 1000Hz No 998 0 1 0
6.67 13.44%
monotonic_raw 18.59 0.16% ---- Yes 0 0 0 0
boottime 17.86 0.09% ---- Yes 0 0 0 0
process 315.95 0.01% ---- Yes 0 0 0 0
thread 296.24 0.02% ---- Yes 0 0 0 0
clock 329.28 0.03% 100Hz No 993 6 6 0
getrusage 384.45 0.01% 1000KHz No 0 0 604 0
ftime 23.50 0.00% 1000Hz No 995 0 4 0
time 3.89 0.03% 1Hz No 1000 0 0 0
TR1 (whitehaven) F4-3200C14-8GFX
== Reported Clock Frequencies ==
tsc 4203MHz
realtime 1000MHz
realtime_crs 1000Hz
monotonic 1000MHz
monotonic_crs 1000Hz
monotonic_raw 1000MHz
boottime 1000MHz
process 1000MHz
thread 1000MHz
clock 1000KHz
time 1Hz
== Clock Behavior Tests ==
Name Cost(ns) +/- Resol Mono Fail Warp Stal Regr
tsc 10.13 0.16% 1000MHz No 0 0 22 0
gettimeofday 30.75 0.22% 1000KHz No 0 0 999 0
realtime 27.29 1.01% ---- Yes 0 0 0 0
realtime_crs 7.88 1.61% 1000Hz No 998 0 1 0
7.84 12.02%
monotonic 27.30 1.06% ---- Yes 0 0 0 0
monotonic_crs 8.19 1.57% 1000Hz No 998 0 1 0
8.17 11.21%
monotonic_raw 27.15 0.93% ---- Yes 0 0 0 0
boottime 27.26 1.01% ---- Yes 0 0 0 0
process 243.79 1.55% ---- Yes 0 0 0 0
thread 232.41 1.11% ---- Yes 0 0 0 0
clock 242.67 0.68% 100Hz No 995 4 4 0
getrusage 285.85 1.24% 1000KHz No 0 0 995 0
ftime 34.96 0.21% 1000Hz No 993 0 6 0
time 4.40 0.61% 1Hz No 1000 0 0 0
