8 Jan
2014
8 Jan
'14
5:54 p.m.
Hi all,
Sorry for this uneducated post, but I am sure there are many people
here who know a lot more about this than me.
This discussion about the Scarlett 18i8 has got me thinking about
latency with USB devices. Is there an accepted buffer size that USB
audio interfaces should be able to use with jackd now? I do seem to be
getting xruns with 128/2 (even occasionally with 256/2 on program
startup/shutdown), but I have not made any particular effort to try to
tune my system for low-latency use.
At 64/2, the sound breaks up in a kind of electronic sounding way
(like a robot voice from the 70s), and linuxsampler (for example)
complains the buffer size is too small.. Not quite sure what's going
on there.
I had a vague idea from discussions years back that there was a hard
lower limit to usb latency, and that all devices, regardless of
quality/chipset would share the same properties in terms of latency
under USB. Presumably this is not the case any more (if it ever was??)
Also, how meaningful is the reported jackd buffer size in terms of
actual latency? When I was trying to help with fixing the kernel bug
on my 2i4, I was told that the actual time between i/o packets was
actually much lower than what was reported by jackd. Could this really
be true?
James
8 Jan
8 Jan
6:35 p.m.
On 01/08/2014 05:54 PM, James Stone wrote:
[..]
This discussion about the Scarlett 18i8 has got me
thinking about
latency with USB devices. Is there an accepted buffer size that USB
audio interfaces should be able to use with jackd now? I do seem to be
getting xruns with 128/2 (even occasionally with 256/2 on program
startup/shutdown), but I have not made any particular effort to try to
tune my system for low-latency use.
try 128/3 or 96/2 .. See the excellent recent explanation from Clemens
on that subject:
http://lists.linuxaudio.org/pipermail/linux-audio-user/2013-December/095401…
[..]
Also, how meaningful is the reported jackd buffer size
in terms of
actual latency?
jack buffer size is only meaningful within jack.
Additional latency introduced by hardware depends on the hardware.
As with any complex system where you cannot precisely know what is
happening: measure it, with jack_delay (or it's son jack_iodelay which
is included with jackd these days).
Results for some USB devices:
http://robin.linuxaudio.org/tmp/vsl1818latency.png
http://wiki.linuxaudio.org/_detail/wiki/jack_latency_tests/latency-ua25-cor…
created with http://gareus.org/gitweb/?p=latentor.git
You'll find some patterns and there usually is a relationship between
the jack-buffersize and the actual round-trip latency. But it's
different for different hardware (and to some extend also
software/drivers,.. the whole stack)
ciao,
robin
9 Jan
9 Jan
12:31 p.m.
[Robin Gareus]
On 01/08/2014 05:54 PM, James Stone wrote:
I was under the impression that in an optimal setup (jackd -d alsa -d
hw:$X), the jack buffer/period setup is identical to what the driver
uses to communicate with the hardware.
In fact, examining the ALSA driver parameters[*] while jackd is
running confirms this for both the UCG-102 USB and the ice1712-based
PCI interface here.
Tim
[*] /proc/asound/card$X/pcm0[cp]/sub0/[hs]w_params
Also, how meaningful is the reported jackd buffer
size in terms of
actual latency?
jack buffer size is only meaningful within jack. 
1:18 p.m.
Tim Goetze wrote:
[Robin Gareus]
The Jack buffer/period setup is identical to what Jack's ALSA driver
uses to communicate with the ALSA kernel driver.
On 01/08/2014 05:54 PM, James Stone wrote:
I was under the impression that in an optimal setup (jackd -d alsa -d
hw:$X), the jack buffer/period setup is identical to what the driver
uses to communicate with the hardware. Also, how meaningful is the reported jackd buffer
size in terms of
actual latency?
jack buffer size is only meaningful within jack. In fact, examining the ALSA driver parameters[*] while
jackd is
running confirms this for both the UCG-102 USB and the ice1712-based
PCI interface here.
In most cases, the ALSA buffer/period parameters directly reflect
hardware parameters, but in the case of protocols like USB where it is
not possible to transfer data directly out of a ring buffer, there is an
additional packet queue, which adds latency. (The length of that queue
is either constant or proportional to the period size, depending on the
driver.)
Regards,
Clemens
2:26 p.m.
[Clemens Ladisch]
In most cases, the ALSA buffer/period parameters
directly reflect
hardware parameters, but in the case of protocols like USB where it is
not possible to transfer data directly out of a ring buffer, there is an
additional packet queue, which adds latency. (The length of that queue
is either constant or proportional to the period size, depending on the
driver.)
Thanks you Clemens for clearing that up. How would one go about
determining the size of this queue between ALSA and USB?
And is it correct to assume that in a best-case scenario where the
sample clock is synchronised to the USB clock and the period size
coincides with the interval at which USB frames are signalled, the
additional latency will be one period?
Cheers, Tim
10 Jan
10 Jan
8:48 a.m.
Tim Goetze wrote:
[Clemens Ladisch]
In the case of the current version of snd-usb-audio, the queue has the
same length as the buffer, but never more than 18 ms.
In most cases, the ALSA buffer/period parameters
directly reflect
hardware parameters, but in the case of protocols like USB where it is
not possible to transfer data directly out of a ring buffer, there is an
additional packet queue, which adds latency. (The length of that queue
is either constant or proportional to the period size, depending on the
driver.)
Thanks you Clemens for clearing that up. How would one go about
determining the size of this queue between ALSA and USB? And is it correct to assume that in a best-case
scenario where the
sample clock is synchronised to the USB clock
Pro devices typically don't do this.
and the period size coincides with the interval at
which USB frames
are signalled,
This does not happen with Jack, where period sizes typically are a power
of two.
the additional latency will be one period?
These two conditions have nothing to do with the queue length; they
ensure that USB interrupts happen exactly at period boundaries, i.e.,
that there is no jitter in the reported period interrupts.
Regards,
Clemens
11:31 a.m.
On Fri, Jan 10, 2014 at 7:48 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
Tim Goetze wrote:
Hi Clemens!
Is there anything that happened to snd-usb-audio (or the underlying
usb kernel code) between 3.0.36 and 3.6+ that might explain why it is
no longer possible to get clean audio with a frame/period size of less
than 128/2 using jack on the Scarlett 2i4?
James
[Clemens Ladisch]
In the case of the current version of snd-usb-audio, the queue has the
same length as the buffer, but never more than 18 ms.
In most cases, the ALSA buffer/period parameters
directly reflect
hardware parameters, but in the case of protocols like USB where it is
not possible to transfer data directly out of a ring buffer, there is an
additional packet queue, which adds latency. (The length of that queue
is either constant or proportional to the period size, depending on the
driver.)
Thanks you Clemens for clearing that up. How would one go about
determining the size of this queue between ALSA and USB?
3760
days inactive
3762
days old
linux-audio-user@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Clemens Ladisch -
James Stone -
Robin Gareus -
Tim Goetze