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 _______________________________________________ Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx
