I stubbled over this topic below after stumbling over a topic in the changes for kernel.
Paul Davis suggest that small buffers can be a chalange for some hardware. After reading the changes to kernel 5.14.2 it seems more likely to be a chalange for the developers of kernel drivers.
With the 5.14.2 or newer was possible to go from 64 to 32 samples, 0.7 ms 3 periods. Using Jack and FFADO with Focusrite Saffire pro26.
Pulse Audio is not disconnected. It is possible to have Pulse play something on the Soundblaster CA0132 while tracking USB keyboard with the Focusrite,
Maybe we should collect some $ to pay someone to do what the changes is suggesting?
Here is the Changes
ALSA: usb-audio: Work around for XRUN with low latency playback
commit 4267c5a8f3133db0572cd9abee059b42cafbbdad upstream.
The recent change for low latency playback works in most of test cases
but it turned out still to hit errors on some use cases, most notably
with JACK with small buffer sizes. This is because USB-audio driver
fills up and submits full URBs at the beginning, while the URBs would
return immediately and try to fill more -- that can easily trigger
XRUN. It was more or less expected, but in the small buffer size, the
problem became pretty obvious.
Fixing this behavior properly would require the change of the
fundamental driver design, so it's no trivial task, unfortunately.
Instead, here we work around the problem just by switching back to the
old method when the given configuration is too fragile with the low
latency stream handling. As a threshold, we calculate the total
buffer bytes in all plus one URBs, and check whether it's beyond the
PCM buffer bytes. The one extra URB is needed because XRUN happens at
the next submission after the first round.
Fixes: 307cc9baac5c ("ALSA: usb-audio: Reduce latency at playback start, take#2")
Signed-off-by: Takashi Iwai <firstname.lastname@example.org>
Signed-off-by: Greg Kroah-Hartman <email@example.com>