I don't know about the firewire latency, but the rm-series ad/da roundtrip is 3.2ms compared to the x32 0.8ms so you need to consider that latency difference as well if you are comparing between the systems.

Last I checked, as reported by Studio One, rtl was in the 6-8ms range at a buffersize of 64.

That's disappointing. I'd be happy with round trip latency through a PC that's as good as the X32 but not worse.

Actually, I just looked up what I was getting, and I was wrong in my previous post. At buffer of 64, studio One reported:

in 1.84/81 samples
out 2.49/110 samples

Sorry about that. Let me know if you need more information. The results are from the win 8 desktop in my sig.

Cheers Matt

Thanks for checking that. I wonder what that's reporting, I'm guessing it's the ASIO buffers, maybe with the FireWire buffer included. So there'll be another 3ms on top for the ad/da for round trip.

Is a buffer size of 64 the smallest available on the driver?

The best way to be sure of round trip latency is something like the free centrance latency check utility. Connect out 1 to in 1 (from the asio driver perspective) and it sends a quick pulse out and measures the round trip.

I think I have gotten the buffer to 32, but I may be remembering my Firestudio Tube. I pretty much use the functions of the mixer when tracking, so buffer and latency are not really on my radar to be honest.

Thanks for the link to the latency checker. I'll give this a run when I get home today, and post up what I am getting. I have used the other rtl tool, which works, but the text is all jacked up and unreadable after it runs, so kinda useless.

I'll be back. If not later today, I can do it tomorrow for sure.

Thanks. Really appreciate your help with this query.

I've finally decided to stop messing about and have ordered an RM16ai. Soon I shall be able to answer this question for my self

I've bought it with a 30day money back if you're not happy with your purchase, so worst case I can always send it back. Seem to have got a good deal on dante card too. I've been wanting to play with that for quite some time.

A quick update in case anyone else is asking themselves this question.

At 44.1k samples/s with an asio buffer size of 64 samples, the analogue in to analogue out latency via firewire is 6.05ms. It drops a bit below 6ms at 48k

The tool I was using, CEntrance latency tester, wouldn't initialise the asio driver at anything above 48k.

This is pretty good performance and slightly better than I could achieve with an X32 rack over USB. The X32 has much faster converters, and offers better in to out latency than the Presonus kit. However, despite an asio buffer size of 32 the X32 through a PC was about 6.25ms. It's a negligible difference but taking the faster converters and smaller asio buffer into account this demonstrates the extra buffering that exists on USB.

matthewseymour wroteThis is pretty good performance and slightly better than I could achieve with an X32 rack over USB. The X32 has much faster converters, and offers better in to out latency than the Presonus kit. However, despite an asio buffer size of 32 the X32 through a PC was about 6.25ms.

I know the round trip latency of an x32 connected by FireWire is about 6.4ms

I assume that you have the x-uf card installed. Are you saying that the usb on the x-uf is faster than its firewire option?

Have you been able to test using the x-usb also?

I'm on mac nowdays and don't have a good pc to do high performance tests on and I'm not aware of any latency tester on mac (unless doing it manually in a daw).

Hi Roblof,

The x32 I tried had the X-USB card installed, which I believe has been the factory standard for a little while. I'm not sure if the Firewire card is available as an option or not.

I found the Presonus RM connected by firewire to have slightly less latency. We're talking 10ths of a ms difference but once you take into consideration the faster converters on the X32 it means the Presonus is getting the data in and out of the computer quite a bit quicker.

With a normal safety and buffer size of 64 samples, I was able to run the Presonus reliably. The X32 was also running with the lowest buffer size of 32 samples, I did get some dropped buffers in an extended test. So for reliability on my system I'd need to push the buffer up to at least 64 samples, which then adds even more latency.

Bottom line is the Presonus wins with a direct to computer connection. As soon as you're using something like Dante you may find, everything else being equal, you then get the benefit of the faster converters in the Behringer for a lower overall latency. It really depends whether 1ms matters to you.

The trap I fell into was, wrongly, assuming that since the Behringer driver offers a buffer size of 32 while the Presonus has a lowest setting of 64 that would mean the Behringer has low latency. It seems that USB has more buffering that's separate from any drivers or if the driver has control of the USB buffers then these are not reflected in the UI. Quite a few people have been saying that Firewire is always better for a reliable data stream than USB. So for audio and video purposes Firewire, as designed, is a better interface than USB. That ignores the fact Apple declared Firewire dead and nothing offers it as standard any more. Still, I think networked audio links are the future anyway. I've put my money into Dante links for my system.

matthewseymour wroteHi Roblof,

The x32 I tried had the X-USB card installed, which I believe has been the factory standard for a little while. I'm not sure if the Firewire card is available as an option or not.

Thomann sells the x-uf as an option card.

http://www.thomann.de/gb/behringer_x_uf.htm

I don't have any x-usb cards anylonger as I swapped my x-usb for an x-uf with a friend who doesn't have firewire so it was a win-win .

I found the Presonus RM connected by firewire to have slightly less latency. We're talking 10ths of a ms difference but once you take into consideration the faster converters on the X32 it means the Presonus is getting the data in and out of the computer quite a bit quicker.

Sounds like the RM-drivers are highly optimized. RME also uses their own fast drivers that does some magic stuff under the hood.

With a normal safety and buffer size of 64 samples, I was able to run the Presonus reliably. The X32 was also running with the lowest buffer size of 32 samples, I did get some dropped buffers in an extended test. So for reliability on my system I'd need to push the buffer up to at least 64 samples, which then adds even more latency.

Bottom line is the Presonus wins with a direct to computer connection. As soon as you're using something like Dante you may find, everything else being equal, you then get the benefit of the faster converters in the Behringer for a lower overall latency. It really depends whether 1ms matters to you.

This is good info and I think it just shows that latency from different manufacturers are more or less equal nowdays, with some special exceptions of course.

The trap I fell into was, wrongly, assuming that since the Behringer driver offers a buffer size of 32 while the Presonus has a lowest setting of 64 that would mean the Behringer has low latency. It seems that USB has more buffering that's separate from any drivers or if the driver has control of the USB buffers then these are not reflected in the UI. Quite a few people have been saying that Firewire is always better for a reliable data stream than USB. So for audio and video purposes Firewire, as designed, is a better interface than USB. That ignores the fact Apple declared Firewire dead and nothing offers it as standard any more.

There is some kind of an usb hardware buffer that you normaly can't tweak. Some drivers are able to override that buffer setting but might render usb unstable unless you know what you are doing. I think this is what presonus and rme are doing in their usb drivers.

Still, I think networked audio links are the future anyway. I've put my money into Dante links for my system.

I tend to agree on this one. When we are on 10gbit networks dante/avb/aes67 will just happily go along with the speed increase.

I believe you're right about the USB buffers. There are things that can be tweaked, but at risk. The other issue with USB is it requires the CPU to poll the interface for data. Reducing buffer sizes can have a negative effect on the overall system load, whereas firewire can stream data without regular polling. At least, that's my understanding.

Matthew, I found this article to be very interesting when it comes to networked audio. Hopefully there will also be an asio equivalent as well in a near future

http://www.mondodr.com/merging-technolo ... -25-years/

I believe Merging already have a Ravenna ASIO driver that works with their kit. AES67 is coming to most Dante kit, and a lot of AVB kit as well. I think Presonus have indicated their AVB card should be able to support AES67. I suspect you'll find that AES67 will become an interoperability thing that will work with almost any networked audio device (at least that's my hope) but each of the standards or proprietary offerings will have their own way of keeping the latency low.

matthewseymour wroteI believe Merging already have a Ravenna ASIO driver that works with their kit.

Yes, but I was told it only supported their own products, or at least one device needed to be present on the network.

There is a free 8ch(?) driver for windows but it seem to only support wdm.

AES67 is coming to most Dante kit, and a lot of AVB kit as well. I think Presonus have indicated their AVB card should be able to support AES67.

Hopfully it will come to most of the dante-enabled products. However, It is up to the manufacturer of the device to implement aes67 support in the customized firmware. It is probably a safe bet though that newly developed products using the audinate dante hardware will have aes67 enabled by default.

I'd be surprised if the presonus avb interface would support aes67. My bet is that if presonus implements aes67, then it will be using the dante card for this.

Where have you heard that a lot of avb kit will have aes67 implemented as well?

I suspect you'll find that AES67 will become an interoperability thing that will work with almost any networked audio device (at least that's my hope) but each of the standards or proprietary offerings will have their own way of keeping the latency low.

Someone needs to create an avb/aes67 bridge I think. Perhaps the rm-mixers can become a bridge in the future?

An interesting addition to aes67 is aes70. There seems to be a lot going on in that area currently...

I can't remember to be honest... It was a post by the beardmaster general Ray Tantzen I think. Searching now I can only find posts that seem really close to the mark but are in fact by me... oh well. My understanding is AES67 can be an interoperability layer between AVB, Dante and other kit. It's one of the reasons why Audinate shifted their development effort from supporting AVB to AES67. This is interesting: https://www.youtube.com/watch?v=E_E5JEVGH9c

Of course that comes from the Audinate perspective, so it isn't unbiased, but it helps explain how AES67 fits in. For converting, something like the Multiverter from appsys.ch (still to be released) will convert from anything to... pretty much anything.

Also, this page has a bit more information about how AVB and AES67 can fit together. Beyond this level, you need to get into reading the standards to understand it. It certainly all depends on whether manufacturers decide to implement things.