SPDIF output audio gaps
Hi there an thank you for the extensive reply :-).
I wasn't aware that this thread had actually been posted (I expected some kind of notification after the moderation queue), otherwise I would've posted this as resolution earlier.
I found a "fix" for the issue: disabling the cluster-sleep CPU idle state (echo 1 | tee /sys/devices/system/cpu/cpu*/cpuidle/state2/disable) as well as (potentially, not 100% sure yet if this is also required) setting the cpufreq governor to performance. This not only allows fluent 96 kHz playback, but also allows rsync+ssh to transfer at ~80 MiB/s instead of ~65 MiB/s, and allows rsync without SSH (via rsyncd) to reach GbE linerate (~112 MiB/s), instead of also crawling at ~65 MiB/s. I initially thought those were unrelated issues, but they weren't, apparently.
To me, it thus seems that this is some weird power management issue where the CPU (or the kernel?) decides that cluster-sleep is ok to enter, when it in fact introduces too much latency for audio (and other things) to work reliably. Initially, I tried to disable cluster-sleep only on cpu0, because that was where all the interrupts came in, but that was less reliable than disabling it on all CPUs (potentially because mpd got scheduled to a cpu != 0 and it took too long to wake it up? don't know, and at this point I already sank multiple days in debugging it and I'm not very keen on testing more unless it helps to provide an upstream fix).
Thank you for the TOSLINK offer, but given the resolution above, I'm pretty sure that this is not an electrical issue :-).
kind regards,
jssfr
P.S.: If you wonder how we figured that cluster-sleep thing out … I wanted to try plain aplay again without mpd so I ran ffmpeg to convert a file to wav… and while ffmpeg was running, things were completely smooth. We then thought this was I/O related and tried to keep the source device busy with pv /dev/sdb >/dev/null, but that didn't quite do the trick (and after poking around in power saving stuff of that device, I also had no clue what could possibly be going on). Then I ran stress -c 7 and that fixed everything and so we came up with the idea that this must be in fact CPU powersaving going wrong.
P.P.S.: This also explains why *lowering* the buffer sizes helped in mpd… more cpu load = less cpuidle = less chance to mess the timing up.
I wasn't aware that this thread had actually been posted (I expected some kind of notification after the moderation queue), otherwise I would've posted this as resolution earlier.
I found a "fix" for the issue: disabling the cluster-sleep CPU idle state (echo 1 | tee /sys/devices/system/cpu/cpu*/cpuidle/state2/disable) as well as (potentially, not 100% sure yet if this is also required) setting the cpufreq governor to performance. This not only allows fluent 96 kHz playback, but also allows rsync+ssh to transfer at ~80 MiB/s instead of ~65 MiB/s, and allows rsync without SSH (via rsyncd) to reach GbE linerate (~112 MiB/s), instead of also crawling at ~65 MiB/s. I initially thought those were unrelated issues, but they weren't, apparently.
To me, it thus seems that this is some weird power management issue where the CPU (or the kernel?) decides that cluster-sleep is ok to enter, when it in fact introduces too much latency for audio (and other things) to work reliably. Initially, I tried to disable cluster-sleep only on cpu0, because that was where all the interrupts came in, but that was less reliable than disabling it on all CPUs (potentially because mpd got scheduled to a cpu != 0 and it took too long to wake it up? don't know, and at this point I already sank multiple days in debugging it and I'm not very keen on testing more unless it helps to provide an upstream fix).
Thank you for the TOSLINK offer, but given the resolution above, I'm pretty sure that this is not an electrical issue :-).
kind regards,
jssfr
P.S.: If you wonder how we figured that cluster-sleep thing out … I wanted to try plain aplay again without mpd so I ran ffmpeg to convert a file to wav… and while ffmpeg was running, things were completely smooth. We then thought this was I/O related and tried to keep the source device busy with pv /dev/sdb >/dev/null, but that didn't quite do the trick (and after poking around in power saving stuff of that device, I also had no clue what could possibly be going on). Then I ran stress -c 7 and that fixed everything and so we came up with the idea that this must be in fact CPU powersaving going wrong.
P.P.S.: This also explains why *lowering* the buffer sizes helped in mpd… more cpu load = less cpuidle = less chance to mess the timing up.