[alsa-devel] snd-usb-audio Buffer Sizes and Round Trip Latency

[Takashi Iwai]

On Tue, 23 Oct 2018 16:08:22 +0200,
Pierre-Louis Bossart wrote:
> 
> 
> >>>> Linux 4.17.14, Class Compliant Mode (snd-usb-audio, ALSA backend):
> >>>> 16/2 32 + 80 ~ 2.333 ms
> >> What are these numbers?  Are these lines supposed to in the format
> >> expressed by the first formula above?  If they are, how come
> >> "block_size/periods" shows up as a pair of numbers "16/2" but
> >> "block_size*periods" shows up as a single number "32"?
> >>
> > To interpret "16/2 32 + 80 ~ 2.333 ms"
> > Block size: 16 samples
> > Periods: 2 (one period for playback + one period for recording when
> > determining round trip latency)
> > The minimum round trip latency is: 16 * 2 = 32 samples
> > However, I measured 112 samples round trip latency which is an
> > additional delay of 80 samples (32 + 80 = 112).
> > 112 samples at 48000 Hz is 112 / 48000 * 1000 is approximately 2.333
> > ms measured round trip latency.
> 
> ok, so what problem are you trying to fix?
> 
> Are you concerned about the latency numbers (but then they seem lower
> on Linux and latency concerns with large buffers are a self-negating
> proposition)? are you concerned about the variable delay that doesn't
> seem to exist on MacOS or Windows? Are you trying to match the
> performance of the RME driver on MacOS?
> 
> I am not sure how this comparison is done btw, the delay includes both
> buffering on the device side before reaching the analog parts as well
> as buffering on the OS side. While the former should be constant, the
> latter depends a great deal on implementation, not sure there are
> direct lessons to be applied to ALSA. I also see
> inconsistent/non-linear results where with a larger block size the
> delay is smaller, e.g.
> 
> 256/2 512 + 650 ~ 24.208 ms
> 2048/3 6144 + 633 ~ 141.188 ms

Independently from the measurement done in this thread, actually,
there is a known latency source in the playback path in USB-audio
driver code -- which I mentioned in the audio mini conf in the last
year: namely, the USB-audio driver starts streaming at prepare time
for playback, not at the trigger-START time.  This is a sort of
workaround to make the device looking similar to the standard
ring-buffer behavior.

Maybe moving the start at trigger (like the capture direction) would
reduce this artificial latency, but it makes the driver behaving in an
unexpected manner.  Then it may wake up for period_elapsed soon after
the stream start with a large runtime->delay value, as the data in
in-flight URBs are seen as already "processed".


thanks,

Takashi