Improvements in latency?

[rerdavies]

Stable, no under-runs, with plugins using 85% of available CPU, 64x3 buffer configuration, MOTU M2 USB audio adapter!

I'm not sure when it happened, but all of a sudden I seem to be getting it.

I was doing some testing on changes made to audio handling, hoping to cause ALSA audio to get upset, I added a TooB Nam plugin AND a ToobML plugin with one of the large Proteus models to the same preset. And it ran stably with NO under-runs! At 85% CPU use, with a 64x3 buffer configuration. (Also seems fine at 32x3 and 32x4).

There is a fix in TooB NAM which prevents memory allocations in the audio thread (a bug in the underling Neural Amp Modeler library, which was fixed and pushed back upstream to Steven Atkin's projec) which allows NAM to run with less variability in each audio frame.

There were a bunch of updates to audio subsystems, and drivers in a recent Raspberry Pi OS release. I'm wondering whether Raspberry Pi OS has made changes to Raspberry Pi OS that accounts for the difference. Very reasonable things that might account for the differences: updated device drivers for non-audio devices that have full RT_PREEMPT patches applied.

At any rate, I am quite amazed by this. I have never seen audio work stations on any OS running stably with 85% plugin CPU use.

So, I'm asking users of PiPedal to give me some feedback on what kind of CPU use works for you while still not under-running, as well as what kinds of buffer configurations are working for you, when you're using the latest release of PiPedal with full Raspberry Pi OS updates applied. applied.

I'm also curious about whether I should be allowing things like 16x6 or 16x8 buffer configurations. These sorts of buffer configurations do work, and at first glance, they seem to be surprisingly stable. And I do have reason to think that 32x4 might actually be more stable than 64x3, while providing even lower latency. But I haven't yet done sufficient testing to make that an actionable point. So I'm asking.

In passing, so you know: graphics operations in buster have a dire effect on audio stability. Much more so than in buster. Just moving the cursor will cause underruns on my system even with large audio buffers. The solution: run headless, or disconnect your HDMI cable. Bookworm seems to shut down the GPU if there's no display attached, which is a very good thing for PiPedal. That may not be surprising to you, but it is quite a big change from previous versions of Raspberry Pi OS. I suspect that the problem is more than one of relative priority of GPU and audio interrupts, and make have more to do with the fact that graphics operations are going to put a heavy load on CPU L2 memory caches. The heavyweight plugins (ML, NAM, and the convolution plugins) are carefully optimised to make best use of CPU L1 and L2 memory caches. So even low priority processes can cause audio unde-runs can and will cause audio under-runs if they do big flat memory operations that invalidate the caches being used by real-time audio.