On 13.03.23 16:17, Len Ovens wrote:
On Sun, 12 Mar 2023, David W. Jones wrote:
On March 12, 2023 1:17:25 PM HST, Fons Adriaensen
<fons@xxxxxxxxxxxxxx> wrote:
P N delay (ms)
------------------
256 2 11.369
192 2 8.702
128 2 6.035
96 3 6.702
48 3 3.702
P < 128 required 3 periods buffering.
P < 48 was unstable.
Ciao,
My limited experience with USB audio is that it required 3 periods.
At lower latencies that would be true, as listed above. Note that it is
stated periods less than 128 require 3 periods. This is because USB
audio does not send periods over it's wire but rather 1ms chunks that
have to be assembled into period sized buffers inside the computer.
Those 1ms chunks are not synced to the media clock but arbitrary size
and timing. By the time the period size reaches 128, there are enough
1ms cycles involved that two period buffers work fine because they are
an artificial construct anyway. I am sure I have glossed over many
details ... Basically, USB was not designed with audio in mind. Also
bear in mind that those who design most consumer audio, consider 30ms or
less as "low latency". I think even 8 or 16 foot pipes sound much faster
than that.
I am not an expert on USB driver / kernel implementation, but
measurements show that the timing of jack callbacks using USB sound
cards is not regular. When calculating period time histograms I usually
get two or three peaks, only on rare occasions (e.g., 1ms block sizes,
but not with all sound cards) only a single peak. Often, none of the
peaks is related to a 1 ms grid.
I can use lower fragment sizes than 1ms even with N = 2, but then the
usable CPU load is much smaller, and dropouts will occur even at load of
around 20% or similar.
All this is on 5.15.0-67-lowlatency and similar kernels (different
Ubuntu LTS versions tested), and on Intel CPUs/chipsets.
When I look at the timing on MacOS, I measure round trip delays which
seem to indicate that MacOS (monterey on M1) is always using N = 3, even
when I configure N = 2 in jack. However, there is barely any jitter in
callback timing (below 1 sample at 48 kHz, even for P = 16). Still the
round trip latency was about 1-3 ms larger than on Linux.
Based on the measurements I have the impression that more is going on in
the USB audio driver than just 1ms packages.
Best,
Giso
Len
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx
_______________________________________________
Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx
