Modartt user forum - Latency jump in Linux kernel 5.10

Re: Latency jump in Linux kernel 5.10

null@example.com (subyekt) — Mon, 11 Jan 2021 21:14:05 +0000

I found the issue with my Linux system.

Apparently, along with the kernel update, the system also updated the CPU speed scaling policy setting (or set it for the first time, I don't know honestly). It was now on 'powersave'. I discovered this by looking closely at the CPU performance info in the options page. The CPU frequency was jumping far more, and over a wider range, than before.

You can check with:
# cpupower -c all frequency-info

I set it to 'performance':
# cpupower -c all frequency-set -g performance

Everything is as before again. No more latency issues (44.1 kHz, 2x 64 sample buffers) The above command does not set the policy permanently. I have seen that there are ways to set it upon boot.

Re: Latency jump in Linux kernel 5.10

null@example.com (subyekt) — Fri, 08 Jan 2021 11:57:24 +0000

Thanks for your response.

openSUSE Tumbleweed is a rolling release with a very short time between kernel release and roll-out (typ. 2 to 3 weeks). The current version I have is 5.10.4-1 So very occasionally you end up with a non-working system, especially on newer hardware, but reverting to the old kernel is always possible, even rolling back an entire update using btrfs snapshots. So I have a workaround.

This is not a real-time optimized kernel, nor does it have preempt-rt applied. But the performance of the default was more than enough. jackd has the right privileges.

The reason I'm bringing it up because it is in our interest to raise an issue with new kernel design as quickly as possible.

Right now I'm suspecting the newest Spectre mitigations. On the other hand, as I said, it could also be a problem with jackd or xhci/libusb so I would appreciate feedback from others if they're running into a similar problem.

I'll certainly will have a look at your script. Thanks again.

Re: Latency jump in Linux kernel 5.10

null@example.com (varpa) — Wed, 06 Jan 2021 19:36:55 +0000

Is the only thing changed the kernel, or did you do a new install? If it is a just a new kernel, can you revert to the old kernel. Unless there is a compelling reason to use the new kernel, you could just stick with the old one. Is the new kernel compiled for low-latency or realtime (RT), either one of these is best for real-time audio performance? Is the new kernel running in Performance mode (as opposed to Powersave or some other mode)? Does Jack have realtime privileges? You can also try this realtime scan script: https://github.com/raboof/realtimeconfi...ickScan.pl

Latency jump in Linux kernel 5.10

null@example.com (subyekt) — Wed, 06 Jan 2021 10:45:54 +0000

It seems that the execution time for Pianoteq 7 has increased on the new kernel 5.10.

It also happens on Pianoteq 6 and other sound applications such as GrandOrgue. I'm using jackd, and killing pulseaudio does not help. I'm using an Intel Gen10 i3 NUC with a Behringer UMC404 MIDI + Audio interface. The Linux distribution is openSUSE Tumbleweed.

The CPU time was around 10..15% while playing, without frame misses. Frame misses did occur when e.g. unlocking the screen but otherwise no problems.

Now it is between 35 and 45%, causing frame misses ('crackling') frequently. The frame misses occur in bursts, and several times per minute.

It is also possible that this is a jackd or USB issue. Again, it worked admirably before 5.10.

Did others observe this as well ? Is there a way to debug this or somehow provide information to the kernel mailing list ?