Differences in latency between USB and internal audio interfaces

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Differences in latency between USB and internal audio interfaces

Luis Garrido-4
Hi, there.

So, I was doing these jackd latency measurements and found some weird
results when it came to USB devices. I was expecting the latency to be
an addition of jackd's reported input and output latencies plus an
approximately constant hardware latency due to A/D and D/A conversion
and assorted bus-hopping.

Motherboard-integrated HDAs seem to behave that way, but it puzzled me
that USB devices were adding one extra period to the measured latency,
up to a buffer size of 2048 where it seemed to only add an extra 1024
frames.

Googled some and found this LAU thread:

http://old.nabble.com/using-jdelay-td22843924.html

where Fons provides some values that didn't corroborate my findings.

I got in touch with fellow LAD Robin Gareus, who happened to have done
something similar not long ago. We traded some mails, got all worked
up, cooked up a script to batch-run jack_delay and found out his
equipment did exhibit this anomaly, too.

I have tidied up our results and uploaded them here:

https://spreadsheets.google.com/ccc?key=0AnYujB_pZj05dG82SndrRkpfVklqTW9RZE03bjl6dXc&hl=en

Robin wikified them and threw in some gnuplots at:

http://wiki.linuxaudio.org/wiki/jack_latency_results

We were wondering why this happens and why Fons' results are
different. Could someone who knows well the inner workings of
jack/alsa perhaps shed some light on this, please?

Cheers,

Luis
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Differences in latency between USB and internal audio interfaces

j4nKy
USB devices don't work like PCI.  you don't tell a USB device that
you're going to be mmap'ing data to a buffer where the device can
read it.  the USB stack sends data from the buffer to the device.

dunno the particulars of how this is handled on linux (specifically,
whether or not data in transit is considered part of the audio buffer
and whether the "hardware position" in the buffer advances when a
request is sent or when it's ack'd) but it's considerably more
complicated than a regular PCI soundcard.

On Wed, Dec 08, 2010 at 05:28:37PM +0100, Luis Garrido wrote:

> Hi, there.
>
> So, I was doing these jackd latency measurements and found some weird
> results when it came to USB devices. I was expecting the latency to be
> an addition of jackd's reported input and output latencies plus an
> approximately constant hardware latency due to A/D and D/A conversion
> and assorted bus-hopping.
>
> Motherboard-integrated HDAs seem to behave that way, but it puzzled me
> that USB devices were adding one extra period to the measured latency,
> up to a buffer size of 2048 where it seemed to only add an extra 1024
> frames.
>
> Googled some and found this LAU thread:
>
> http://old.nabble.com/using-jdelay-td22843924.html
>
> where Fons provides some values that didn't corroborate my findings.
>
> I got in touch with fellow LAD Robin Gareus, who happened to have done
> something similar not long ago. We traded some mails, got all worked
> up, cooked up a script to batch-run jack_delay and found out his
> equipment did exhibit this anomaly, too.
>
> I have tidied up our results and uploaded them here:
>
> https://spreadsheets.google.com/ccc?key=0AnYujB_pZj05dG82SndrRkpfVklqTW9RZE03bjl6dXc&hl=en
>
> Robin wikified them and threw in some gnuplots at:
>
> http://wiki.linuxaudio.org/wiki/jack_latency_results
>
> We were wondering why this happens and why Fons' results are
> different. Could someone who knows well the inner workings of
> jack/alsa perhaps shed some light on this, please?
>
> Cheers,
>
> Luis
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
[hidden email]
SDF Public Access UNIX System - http://sdf.lonestar.org
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Differences in latency between USB and internal audio interfaces

Fons Adriaensen-2
In reply to this post by Luis Garrido-4
On Wed, Dec 08, 2010 at 05:28:37PM +0100, Luis Garrido wrote:

> http://wiki.linuxaudio.org/wiki/jack_latency_results
>
> We were wondering why this happens and why Fons' results are
> different. Could someone who knows well the inner workings of
> jack/alsa perhaps shed some light on this, please?

What seems to happen is that for USB devices the latency
overhead increases with period size. This also follows from
my results you referred to, there's no contradiction there.

I suspect that for USB devices the 'period size' just refers
to the buffering that ALSA is adding between the raw USB
layer and the ALSA device layer as seen by applications.
The hardware is probably unaware of this 'period' and doing
just the same thing all the time.

Clearly, for larger period sizes ALSA is adding more buffering
than strictly necessary. It could be a design error, or there
may be good reasons for doing so.

One good reason could be that for USB the dominant timing
uncertainty is not between the driver and the user space
application (i.e. task scheduling), but within the USB
interface itself. In that case, increasing the period size
without at the same time adding more buffering would not
help to resolve timing problems, in other words there would
be no advantage to using larger periods.

The 'clean' solution in that case would be for ALSA to allow
setting the period size and any extra buffering separately,
but the API doesn't provide such an 'extra buffering' parameter.
So using the period size to control it may be the only solution.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Differences in latency between USB and internal audio interfaces

Luis Garrido-4
On Wed, Dec 8, 2010 at 7:08 PM,  <[hidden email]> wrote:
> What seems to happen is that for USB devices the latency
> overhead increases with period size. This also follows from
> my results you referred to, there's no contradiction there.

Your UA-5 appears to exhibit a pretty constant overhead between -p 64
and 512, doesn't it? Then it grows a little at -p 1024.

64 2 387.9 259.9
128 2 515.9 259.9
256 2 771.9 259.9
512 2 1283.9 259.9
1024 2 2355.9 307.9
64 3 451.9 259.9
128 3 643.9 259.9
256 3 1027.9 259.9
512 3 1795.9 259.9
1024 3 3379.9 307.9


Luis
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Differences in latency between USB and internal audio interfaces

Clemens Ladisch
In reply to this post by Fons Adriaensen-2
[hidden email] wrote:
> Clearly, for larger period sizes ALSA is adding more buffering
> than strictly necessary.

The driver uses a queue of up to 24 ms, or shorter when the period
length is smaller.

> The 'clean' solution in that case would be for ALSA to allow
> setting the period size and any extra buffering separately,
> but the API doesn't provide such an 'extra buffering' parameter.

It would certainly be possible to add such a parameter.


Regards,
Clemens
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Differences in latency between USB and internal audio interfaces

Luis Garrido-4
On Thu, Dec 9, 2010 at 12:36 PM, Clemens Ladisch <[hidden email]> wrote:

> The driver uses a queue of up to 24 ms, or shorter when the period
> length is smaller.

That definitely accounts for the drop in extra buffering at p=2048.
That extra queue is then calculated as min(period, 24ms)?

The point of these questions is whether latency can be calculated as the sum of:

1) A predictable amount proportional to the period size (software buffering).
2) A period length independent value that depends on the hardware
(audio interface and computer) and possibly on the sample rate.

Thus roundtrip latency for PCI devices would be of the form:

L = p * n + K1

where K1 would be experimentally determined and approximately constant
for a given SR.

And for USB devices:

L = p * n + min(p, 24 ms) + K2

Asynchronous mode would add an extra period to both formulas.

Cheers,

Luis
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Differences in latency between USB and internal audio interfaces

Clemens Ladisch
Luis Garrido wrote:
> That extra queue is then calculated as min(period, 24ms)?

There are extra calculations to account for sample clock differences
(the sample clock and the USB clock are typically not synchronous), but,
approximately, yes.

> Thus roundtrip latency for PCI devices would be of the form:
>
> L = p * n + K1
>
> where K1 would be experimentally determined and approximately constant
> for a given SR.

Often, the FIFO size of the sound card's DMA controller also depends on
the audio frame size (i.e., number of channels and sample size).  But K1
is relatively small anyway.

> And for USB devices:
>
> L = p * n + min(p, 24 ms) + K2

Yes.


Regards,
Clemens
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org