20 Jun
2014
20 Jun
'14
2:54 p.m.
Hello folks,
Is there a site/repository somewhere with numbers on audio interface latency?
I'm much interested in doing multichannel live audio processing and
the device latency matters a lot in this case. I'm especially curious
how recent USB audio interfaces provide in this regard. Anyone has any
numbers?
Lastly, here are some numbers for the firewire interfaces Edirol FA-66
and Presonus FIRESTUDIO Project I measured with jack_delay.
FA-66
jackd -Z -t 9999 -d firewire -p 128 -r 44100 -X seq
618.760 frames 14.031 ms
jackd -Z -t 9999 -d firewire -p 64 -r 44100 -X seq
420.924 frames 9.545 ms
jackd -Z -t 9999 -d firewire -p 128 -r 48000 -X seq
618.780 frames 12.891 ms
jackd -Z -t 9999 -d firewire -p 64 -r 48000 -X seq
440.792 frames 9.183 ms
jackd -Z -t 9999 -d firewire -p 128 -r 96000 -X seq
724.485 frames 7.547 ms
jackd -Z -t 9999 -d firewire -p 64 -r 96000 -X seq
560.492 frames 5.838 ms
jackd -Z -t 9999 -d firewire -p 128 -r 192000 -X seq (unstable)
989.556 frames 5.154 ms
FIRESTUDIO Project
jackd -Z -t 9999 -d firewire -p 128 -r 44100 -X seq
543.411 frames 12.322 ms
jackd -Z -t 9999 -d firewire -p 64 -r 44100 -X seq
351.412 frames 7.969 ms
jackd -Z -t 9999 -d firewire -p 128 -r 48000 -X seq
543.438 frames 11.322 ms
jackd -Z -t 9999 -d firewire -p 64 -r 48000 -X seq
351.438 frames 7.322 ms
jackd -Z -t 9999 -d firewire -p 128 -r 96000 -X seq
566.642 frames 5.903 ms
jackd -Z -t 9999 -d firewire -p 64 -r 96000 -X seq
374.642 frames 3.903 ms
Regards,
Robert
20 Jun
20 Jun
3:07 p.m.
On Fri, Jun 20, 2014 at 8:53 AM, Robert Jonsson <spamatica(a)gmail.com> wrote:
Lastly, here are some numbers for the firewire interfaces Edirol FA-66
and Presonus FIRESTUDIO Project I measured with jack_delay.
If you used jack_iodelay, it would do the math for you and show you how
much extra latency is bing caused by the hardware (rather than the period
size).
3:19 p.m.
On Fri, Jun 20, 2014 at 09:07:37AM -0400, Paul Davis wrote:
If you used jack_iodelay, it would do the math for you
and show you how
much extra latency is bing caused by the hardware (rather than the period
size).
jack_delay will do this as well, use the -E option.
jack_delay 0.4.0
(C) 2003-2013 Fons Adriaensen <fons(a)linuxaudio.org>
Measure round trip latency of a soundcard.
Usage: jack_delay <options>
Options:
-h Display this text
-O <playback port> Connect output to named port.
-I <capture port> Connect input to named port.
-E Report excess latency, requires both -I and -O.
The excess latency is the measured value minus the
expected value for the given ports including any
corrections set by Jack's -I and -O options.
Ciao,
--
FA
3:24 p.m.
On Fri, Jun 20, 2014 at 9:19 AM, Fons Adriaensen <fons(a)linuxaudio.org>
wrote:
On Fri, Jun 20, 2014 at 09:07:37AM -0400, Paul Davis
wrote:
and make sure your distribution has packaged and included the new version
of jack_delay :)
of course, since jack2 still isn't sharing the tools/ or headers in the
JACK git repository, the presence of jack_iodelay there doesn't really help
most Linux users at all since they don't have it either.
If you used jack_iodelay, it would do the math
for you and show you how
much extra latency is bing caused by the hardware (rather than the period
size).
jack_delay will do this as well, use the -E option.
4:10 p.m.
On Fri, Jun 20, 2014 at 09:23:58AM -0400, Paul Davis wrote:
On Fri, Jun 20, 2014 at 9:19 AM, Fons Adriaensen
<fons(a)linuxaudio.org>
wrote:
Released 18 April 2011, that is more than three years ago :-)
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
On Fri, Jun 20, 2014 at 09:07:37AM -0400, Paul
Davis wrote:
and make sure your distribution has packaged and included the new version
of jack_delay :) If you used jack_iodelay, it would do the math
for you and show you how
much extra latency is bing caused by the hardware (rather than the period
size).
jack_delay will do this as well, use the -E option.
6:05 p.m.
On Fri, Jun 20, 2014 at 10:10 AM, Fons Adriaensen <fons(a)linuxaudio.org>
wrote:
On Fri, Jun 20, 2014 at 09:23:58AM -0400, Paul Davis
wrote:
and make sure your distribution has packaged and included the new version
of jack_delay :)
Released 18 April 2011, that is more than three years ago :-)
It might even be in Debian Stable, then! :)
On Fri, Jun 20, 2014 at 9:19 AM, Fons Adriaensen
<fons(a)linuxaudio.org>
wrote:
> On Fri, Jun 20, 2014 at 09:07:37AM -0400, Paul Davis wrote:
>
> > If you used jack_iodelay, it would do the math for you and show you
how
> > much extra latency is bing caused by
the hardware (rather than the
period
size).
jack_delay will do this as well, use the -E option.
21 Jun
21 Jun
11:51 a.m.
2014-06-20 18:05 GMT+02:00 Paul Davis <paul(a)linuxaudiosystems.com>om>:
On Fri, Jun 20, 2014 at 10:10 AM, Fons Adriaensen <fons(a)linuxaudio.org>
wrote:
Hehe
Anyway, thanks guys for enlightening me about improving the test results!
Follow up question: from a theoretical perspective, is it likely a usb
2.0 interface would have similar transport latency as firewire? Usb 1
I suppose would be worse due to lower clockspeed.
Regards,
Robert
On Fri, Jun 20, 2014 at 09:23:58AM -0400, Paul Davis wrote:
It might even be in Debian Stable, then! :)
On Fri, Jun 20, 2014 at 9:19 AM, Fons Adriaensen
<fons(a)linuxaudio.org>
wrote:
Released 18 April 2011, that is more than three years ago :-) On Fri, Jun 20, 2014 at 09:07:37AM -0400, Paul
Davis wrote:
> If you used jack_iodelay, it would do the math for you and show you
> how
> much extra latency is bing caused by the hardware (rather than the
> period
> size).
jack_delay will do this as well, use the -E option.
and make sure your distribution has packaged and included the new
version
of jack_delay :)
12:22 p.m.
On Sat, Jun 21, 2014 at 11:51:54AM +0200, Robert Jonsson wrote:
Follow up question: from a theoretical perspective, is
it likely a usb
2.0 interface would have similar transport latency as firewire? Usb 1
I suppose would be worse due to lower clockspeed.
Clock frequency determines the amount of data per time that can
be tranported, not latency. If a slower clock can still handle
the data rate then there is no reason why it should make the
data arrive 'later'.
Every technology will have its particular features and limits.
Nothing will beat a PCI(e) card if that card is designed well.
USB probably won't give you the same advantage at 96 and 192
kHz Firewire offers. But generalisations can be misleading,
and there's really no alternative to measuring each device.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
7:21 p.m.
On Sat, 21 Jun 2014, Robert Jonsson wrote:
Follow up question: from a theoretical perspective, is
it likely a usb
2.0 interface would have similar transport latency as firewire? Usb 1
I suppose would be worse due to lower clockspeed.
As was already stated, clock speed of the interface is not really
relevant. It seems in fact that no one is really interested in USB3
because it does not have any improvement for audio, USB2 is enough. The
limitation with USB1 is bit depth, bit rate and channel count.
In general, throughput and latency are two different things. Larger
packets mean better throughput, but smaller packets mean lower latency.
I am not sure, but it seems to me the USB1.1 audio standard effectively
means that the lowest latency for USB1 is jackd set to 64/2. This is the
smallest buffer size supported. I do not know, but it seems that fire wire
audio is about the same from what I have read (I don't have one of my own
to confirm).
The main trouble with USB is on the MB. Finding a USB port that is not
shared with something else via an internal hub. I think adding a USB card
would make things better, but trying different ports on a laptop gives
good results too. With any audio interface, having it's own irq is
important, I have moved PCI cards to different slots with a big
difference. It shouldn't be, but it seems tunning a computer for audio is
a must still for low latency. Audio is very definately _not_ plug and play
for (semi)pro audio work. There is no silver bullet kernel or distro that
just makes everything work. On my laptop, there is one USB port that gives
good audio... so long as the port next to it is empty... and the wireless
kernel module is unloaded and .... you get the picture :)
--
Len Ovens
www.ovenwerks.net
8:19 p.m.
2014-06-21 19:18 GMT+02:00 Len Ovens <len(a)ovenwerks.net>et>:
As was already stated, clock speed of the interface is
not really relevant.
It seems in fact that no one is really interested in USB3 because it does
not have any improvement for audio, USB2 is enough. The limitation with USB1
is bit depth, bit rate and channel count.
You are probably right about USB3 but with USB1 and USB2 speeds, how
can the clock speed not be relevant? As an example, wouldn't
transferring 1024 frames of float on USB1 (12Mbit) take 2,7ms and only
68us on USB2 (480Mbit)?
In raw throughput that is, there are probably other factors limiting the speed?
Regards,
Robert
9:52 p.m.
On Sat, 21 Jun 2014, Robert Jonsson wrote:
2014-06-21 19:18 GMT+02:00 Len Ovens
<len(a)ovenwerks.net>et>:
Measure round trip. That is the only way to find out. As an aside, if you
have to measure it, does it matter?
In general, the manufacturers seem to have chosen to use the extra through
put on USB2 to add extra bit depth (24bit instead of 16), extra bitrate
(96k or more instead of 48k) and more channels. The latency would end up
being simmilar.
Being realistic... I can set my card to ~.6ms (one way) latency at 48k...
maybe less at 96k but I haven't tried it. However, The dsp inside the
audio interface itself already adds ~1ms of latency. That is 1.6ms one
way. I can double the latency in jack to 1.2ms and the total is now 2.2ms
not that much higher(this is not measured values BTW so the jackd added
latency may be even less of the equation). There is a point where the
latency of the interface itself is the main part of things... and how many
inches away or towards the speaker do I have to move my head to have the
same effect? When is a latency decrease really a gain? It seems to me from
my own experience that a USB1 IF at 64/2 is good enough for live work as
an effects rack or softsynth. For tighter needs the cost for the interface
and the computer to run it goes up. Even audio imaging with multi speakers
using delays for spacial placement is not overly latency dependant so long
as all the channels are in good sync.
--
Len Ovens
www.ovenwerks.net
As was already stated, clock speed of the
interface is not really relevant.
It seems in fact that no one is really interested in USB3 because it does
not have any improvement for audio, USB2 is enough. The limitation with USB1
is bit depth, bit rate and channel count.
You are probably right about USB3 but with USB1 and USB2 speeds, how
can the clock speed not be relevant? As an example, wouldn't
transferring 1024 frames of float on USB1 (12Mbit) take 2,7ms and only
68us on USB2 (480Mbit)?
In raw throughput that is, there are probably other factors limiting the speed?
10:47 p.m.
On Sat, Jun 21, 2014 at 08:19:49PM +0200, Robert Jonsson wrote:
You are probably right about USB3 but with USB1 and
USB2 speeds, how
can the clock speed not be relevant? As an example, wouldn't
transferring 1024 frames of float on USB1 (12Mbit) take 2,7ms and only
68us on USB2 (480Mbit)?
For USB devices period size is just a property of the driver.
Not of the interface, which will be using smaller packets.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
10:57 p.m.
greetings, all!
interesting that this USB latency discussion comes up now, as i'm
re-examining my live performance setup. without having quantified
rigorously, i CAN say that my latency performance before xruns is much
better with a new PCIe USB adapter than with the internal USB ports on
my Lenovo T520.
ART USB Dual Tube Pre (USB 2.0)
using a bunch of pd stuff, plus sooperlooper.
cheers!
.pltk.
--
Peter Lutek
improvising musician in Toronto, Canada
http://peterlutek.com
11:18 p.m.
On Sat, 21 Jun 2014, Peter Lutek wrote:
ART USB Dual Tube Pre (USB 2.0)
Holding the box for one of those in my hand... and yes it does say USB 2.0
on the box. But, the spec looks a lot like USB 1.1 - two channels, 44.1k
or 48k. SO I don't know what the gain is for that. It is interesting
though that there seem to be separate a/d converters for USB and s/pdif so
that one can be set to 44.1 while the other is at 48k. I am not sure how
this would be useful though. The stated A/D latency is .4ms.
The best thing from my POV was that I could take my laptop into the music
store and plug it in and everything just worked. This was not the case
with 2 or 3 other interfaces I tried the same day. (Native Instruments,
and M-audio... can't remember the other now) The only thing missing is
midi.
--
Len Ovens
www.ovenwerks.net
23 Jun
23 Jun
6:43 p.m.
Am Samstag, 21. Juni 2014, 17:27:59 schrieb Peter Lutek:
On 2014-06-21 17:16, Len Ovens wrote:
i add on an M-Audio midisport 2x2 for that... nice and small, and
completely plug'n'play too!
Since when is that? Ii own a midisport 2x2 since many years and it needs the midisport
firmware, I even had to alter the udev rule (patch went upstream I seem to remember) to
make it handle my model revision properly...
I just recently wrote a wiki page about it, for the linuxaudio hardware database, at
http://wiki.linuxaudio.org/hw/m-audio_midisport_2x2 . If there's misleading, not
sufficient or incorrect information I'd like to know to be able to correct/extend that
page.
Thanks, Edgar
ART USB Dual Tube Pre (USB 2.0)
...The only
thing missing is midi.
cheers!
.pltk.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
6:59 p.m.
On 2014-06-23 12:43, Edgar Aichinger wrote:
Am Samstag, 21. Juni 2014, 17:27:59 schrieb Peter
Lutek:
The new ones since a few years are class-compliant and don't need
drivers. I have a 2X2 "Anniversary Edition" from 2012 running on a
debian system with no issues.
Martin
On 2014-06-21 17:16, Len Ovens wrote:
i add on an M-Audio midisport 2x2 for that... nice and small, and
completely plug'n'play too!
Since when is that? Ii own a midisport 2x2 since many years and it needs the midisport
firmware, I even had to alter the udev rule (patch went upstream I seem to remember) to
make it handle my model revision properly...
I just recently wrote a wiki page about it, for the linuxaudio hardware database, at
http://wiki.linuxaudio.org/hw/m-audio_midisport_2x2 . If there's misleading, not
sufficient or incorrect information I'd like to know to be able to correct/extend that
page.
24 Jun
24 Jun
8:38 p.m.
On 2014-06-23 12:59, Martin Peach wrote:
On 2014-06-23 12:43, Edgar Aichinger wrote:
yes, mine is also the "Anniversary Edition", purchased in 2013.
cheers!
.pltk.
Am Samstag, 21. Juni 2014, 17:27:59 schrieb Peter
Lutek:
The new ones since a few years are class-compliant and don't need
drivers. I have a 2X2 "Anniversary Edition" from 2012 running on a
debian system with no issues. On 2014-06-21 17:16, Len Ovens wrote:
i add on an M-Audio midisport 2x2 for that... nice and small, and
completely plug'n'play too!
Since when is that? Ii own a midisport 2x2 since many years and it
needs the midisport firmware, I even had to alter the udev rule (patch
went upstream I seem to remember) to make it handle my model revision
properly...
I just recently wrote a wiki page about it, for the linuxaudio
hardware database, at
http://wiki.linuxaudio.org/hw/m-audio_midisport_2x2 . If there's
misleading, not sufficient or incorrect information I'd like to know
to be able to correct/extend that page. 
21 Jun
21 Jun
8:43 p.m.
On 06/21/2014 07:18 PM, Len Ovens wrote:
On Sat, 21 Jun 2014, Robert Jonsson wrote:
With my Edirol UA-25 lowest possible setting is 48/2 @ 48kHz.
This is the
Follow up question: from a theoretical
perspective, is it likely a usb
2.0 interface would have similar transport latency as firewire? Usb 1
I suppose would be worse due to lower clockspeed.
As was already stated, clock speed of the interface is not really
relevant. It seems in fact that no one is really interested in USB3
because it does not have any improvement for audio, USB2 is enough. The
limitation with USB1 is bit depth, bit rate and channel count.
In general, throughput and latency are two different things. Larger
packets mean better throughput, but smaller packets mean lower latency.
I am not sure, but it seems to me the USB1.1 audio standard effectively
means that the lowest latency for USB1 is jackd set to 64/2. smallest buffer size supported. I do not know, but it
seems that fire
wire audio is about the same from what I have read (I don't have one of
my own to confirm).
With the FireWire interfaces I've owned I could go as low as 16/3 @
48kHz. But settings like this are unusable, DSP load qickly rises as
soon as you start doing something serious. Nice to brag about but that's
about it ;)
The main trouble with USB is on the MB. Finding a USB port that is not
shared with something else via an internal hub. I think adding a USB
card would make things better, but trying different ports on a laptop
gives good results too. With any audio interface, having it's own irq is
important, I have moved PCI cards to different slots with a big
difference. It shouldn't be, but it seems tunning a computer for audio
is a must still for low latency. Audio is very definately _not_ plug and
play for (semi)pro audio work. There is no silver bullet kernel or
distro that just makes everything work. On my laptop, there is one USB
port that gives good audio... so long as the port next to it is empty...
and the wireless kernel module is unloaded and .... you get the picture :)
It's indeed a matter of finding a free USB port. If you don't have any
you have to resort to unloading kernel modules or even unbinding drivers.
Jeremy
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:25 p.m.
On Sat, 21 Jun 2014, Jeremy Jongepier wrote:
On 06/21/2014 07:18 PM, Len Ovens wrote:
I hadn't tried that... or to be honest 32/3. I have been lazy not thinking
outside the 16/32/64/128 box :)
I am not sure, but it seems to me the USB1.1
audio standard effectively
means that the lowest latency for USB1 is jackd set to 64/2.
With my Edirol UA-25 lowest possible setting is 48/2 @ 48kHz. This is the
Is that the DSP load in the audio interface itself or the computer? I have
found that 16/2 at 48k for use with guitarix (in other words as an
effects rack) is very solid. (ice1712 pci interface) I am using a
lowlatency kernel, but not RT. No hyperthreading (got the i5 for that
reason) no CPU frequency changes. Not a super great tunning, but all the
low hanging fruit for sure. Any modern computer should be able to deal
with the load for at least some uses. Though I guess my atom should be
considered "modern"... it does really well down to 64/2, I will have to
try pushing a bit further, but I don't think it will go much lower and
still have cpu cycles to run the SW.
--
Len Ovens
www.ovenwerks.net
smallest buffer size supported. I do not know,
but it seems that fire
wire audio is about the same from what I have read (I don't have one of
my own to confirm).
With the FireWire interfaces I've owned I could go as low as 16/3 @
48kHz. But settings like this are unusable, DSP load qickly rises as
soon as you start doing something serious. Nice to brag about but that's
about it ;)
9:48 p.m.
On 06/21/2014 09:23 PM, Len Ovens wrote:
The computer.
I
With the FireWire interfaces I've owned I could go as low as 16/3 @
48kHz. But settings like this are unusable, DSP load qickly rises as
soon as you start doing something serious. Nice to brag about but that's
about it ;)
Is that the DSP load in the audio interface itself or the computer? have found that 16/2 at 48k for use with guitarix (in
other words as an
effects rack) is very solid. (ice1712 pci interface)
I was referring to USB and FireWire devices. PCI(e) apparently is still
the interface to beat, even my USB2 interface can't go that low without
becoming unstable.
Jeremy
3603
days inactive
3607
days old
linux-audio-user@lists.linuxaudio.org
20 comments
8 participants
participants (8)
-
Edgar Aichinger -
Fons Adriaensen -
Jeremy Jongepier -
Len Ovens -
Martin Peach -
Paul Davis -
Peter Lutek -
Robert Jonsson