On Mon, Mar 13, 2023 at 10:20:01PM +0100, Giso Grimm wrote:
Based on the measurements I have the impression that
more is going on in the
USB audio driver than just 1ms packages.
I'd agree.
When I use alsa_delay with 96/2 things are OK for around 10
seconds, then for another 10 s I get all sorts of weird values,
and finally a stable value that is a few tens of samples higher
than the original. This stable value is different each time
the test is run.
For 48/2, I get unstable values for the first 10 seconds, then
a stable value that is again different each time.
It almost looks as if something tries to adapt to the situation,
but not in a deterministic way.
It's also not clear why 96/2 should go wrong at all with such
a light load. Imagine my sample rate is just a bit low when
measured against the 1 ms clock used by the USB system.
Then occasionally we get 47 samples instead of 48, and the
start of period has to wait for another 1 ms. But that is
only half a period, so it should not have any ill effects
at all if the actual processing time is much shorter.
Re. using Jack on OSX: that is probably Jack2, which unless
you use -S runs in a mode that adds one period to the
round-trip latency. This is done by sending the output of
the previous cycle to the hardware at the start of each
cycle, rather than the output of the current cycle when
it is done. This provides some extra resilience against
xruns, but not as much as -n 3.
Ciao,
--
FA