I just saw that this is probably going in the 5.14 kernel: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=f… This is the description: "USB-audio driver behaves a bit strangely for the playback stream -- namely, it starts sending silent packets at PCM prepare state while the actual data is submitted at first when the trigger START is kicked off. This is a workaround for the behavior where URBs are processed too quickly at the beginning. That is, if we start submitting URBs at trigger START, the first few URBs will be immediately completed, and this would result in the immediate period-elapsed calls right after the start, which may confuse applications. "OTOH, submitting the data after silent URBs would, of course, result in a certain delay of the actual data processing, and this is rather more serious problem on modern systems, in practice. "This patch tries to revert the workaround and lets the URB submission starting at PCM trigger for the playback again. As far as I've tested with various backends (native ALSA, PA, JACK, PW), I haven't seen any problems (famous last words :) "Note that the capture stream handling needs no such workaround, since the capture is driven per received URB." Curious if anyone has a setup that can backport this and see if it changes the behavior of different latency every time you start. If I get time to work on that this weekend, what would be the best setup? Just patch output to input and run jack_iodelay over and over? Have Ardour run latency test multiple times? Both? -- Chris C