You are not logged in. Please login or register.
RME User Forum → ADI-2 & 2/4 Pro series, ADI-2 DAC series → lowest latency interfaces for real time internet music rehearsal
Have ADI-2 PRO (not FS), and a Babyface PRO FS. Want lowest possible latency for chamber music rehearsal at 2 sites 30 miles apart using FarPlay or Sonobus software, Windows laptops. Will the ADI-2 PRO (using external audio mic preamp input) provide similar low latency as the Babyface PRO FS, or do I need another interface (like a Motu M4)?
The Babyface Pro is perfectly fine for this task.
No need to buy anything else, especially not a cheap low-budget piece.
Just be aware. The latency will not vanish it is given by the software with the internet stream.
You may check out Jamulus it was huge hyped during corona by many musicians jamming with friends even overseas.
Regarding BabyFace vs. ADI-2 Pro you’re in the best position to test by yourself.
Check how far down you can set the ASIO buffer on each before they start crackling.
To bring down ADI-2 Pro’s internal latency to almost zero, choose “SD Sharp” AD- and DA-filters.
The dominant factor for latency will always stay the local network (Ethernet preferred above Wlan) and mostly the internet connection.
These are server- and packet-based, not linear 1:1 realtime links.
For curiosity and informative reasons, please report back how it went!
The geographical distance is short, but you should try to use the same provider wherever possible. Otherwise, the geographical distance between the providers’ peering points might result in an increased RTT. RTT is the "Round Trip Time", the latency for "ping packets" (ICMP) to the destination and back.
When I use my provider’s speed test, I get the following RTTs - with VDSL 250/40 Mbps - to servers of the same ISP.
For a server 230 km away from me, RTT is 8 ms; for a server 560 km away, it is already 16 ms.
Converter latencies for RME reference converters and current recording interfaces – such as the BBF Pro FS – are around 5–7 samples for A/D and D/A. That is no more than 0.11–0.16 ms; you can read about this in any RME manual in the ‘Latency and Monitoring’ chapter.
The latencies for transport via USB are significantly higher. You can read about this in my blog article: https://www.tonstudio-forum.de/blog/ent … cts-en-de/
The so-called RTL (Round Trip Latency, i.e. A/D, transport via USB, PC processing, transport via USB, D/A) for the UFX III is 2.9 ms with ASIO buffer sizes of 32 samples (@44.1 kHz); at 512 samples, it is already 24.7 ms.
If your PC hardware is suitable for audio processing and has low DPC latency, it should be possible to use a very low ASIO buffer size of 32 samples. I recommend not using the lowest setting to have a little bit headroom to prevent audio gaps.
The Babyface Pro FS's USB driver allows buffer sizes starting with 48 samples. I would try whether 48 samples work and then use 96 samples to get a little more headroom on top.
I would use the combination of Babyface Pro FS and ADI-2 Pro to also have TotalMix FX for more flexible routing.
The ADAT connection between the two devices will introduce a little latency of 1 or 2 samples; this is a little nothing.
WAN / ISP
|
Internet Router
|
| LAN
|
PC
|
| USB2
|
Babyface Pro FS [cs]---ADAT OUT--------->ADAT IN---ADI-2 Pro---1/2 + 3/4 "monitoring"
\---ADAT IN<---------ADAT OUT---/
Another advantage, you can work with up to 3 headphones on your side.
In your LAN, I would take care, that your internet router - usually a combination of router and switch- are in the same subnet to avoid any additional latency in your LAN due to routing.
Also - as already mentioned by KaiS - avoid wireless, which introduces latency and which is a half-duplex connection, which means that WLAN participants can't send and receive at the same time. Its a must for you to use cabled connections!
To be on the very safe side check that you links are using full-duplex connections.
Usually auto-detection on both sides of a link, e.g. between your PC and the switch port, should result in a fulll-duplex connection. This means, both sides can send and receive packets at the same time.
To keep a long story short: it should work, but autodetection can fail if you have it enabled only on one side.
A mix of autodetection and static settings for speed and duplex can lead to a half-duplex connection.
Then both parties can not send and receive at the same time, instead of this you get a shared network connection, where only one party can send and if the other side sends at the same time, you get a network collision, the sending process is interrupted and needs to be repeated until the shared medium is free. This kills performance in terms of throughput significantly.
What can also be of help, depending on the capabilties of your WAN/LAN router, to prioritize the traffic of this particular PC.
QoS configuration makes most sense end-to-end but is in your case most likely not applicable if you do not have a WAN product that allows for QoS or a LAN structure with multiple switches allowing QOS configuration and other internet user.
The dominant factor for latency will always stay the local network (Ethernet preferred above Wlan) and mostly the internet connection.
These are server- and packet-based, not linear 1:1 realtime links.
Exactly, internet connection latency will be most probably the weakest point. Interface and computer latencies are generaly one order lower.... So, focus should be mainly on reducing latency of internet connection as it makes IMHO most of the overall latency (RTL).... Unless it is some kind of dedicated internet/network infrastructure with higher priorities and so....
I remember from covid times, when I have used Zoom that traffic often went Europe- US-Europe even if all participants were from the same european country....
Usually the latency over the internet is higher, but in a lucky case, not that much.
Internet RTT can be between 5 and 300 ms, usually below ~15 ms within your geographic region.
In a lucky case, below 8 ms. RTL can be between 3 and 93 ms.
If they are lucky, then the RTT over the internet is perhaps below 8 ms. And if you can keep RTL below 10 ms
(best as low as possible), then this might work well even if both sides want to play music with each other.
It might be challenging or even impossible if latencies are higher than 15-20 ms.
For simple rehearsal (music source only from one party), the latency is uncritical.
Sure, I agree, I just wanted to stress, that one should mainly focus on minimazing internet latency, if possible as it is the main source of latency in that case. Improving RTL by few 0,1 miliseconds in situation that internet RTL may be, say, 5-10 ms if one is lucky, does not bring much.
But maybe the group has some kind of low latency network connection, and in that case, latency of interfaces would play the role.
Yes Kubrak, I agree.
Luckily classical music is in general less groove driven as pop music. So timing a little less critical and since it is a rehearsal, imagine the release of playing in the same room at the concert. It also depends a little on where the rehearsal is ment for.
RME User Forum → ADI-2 & 2/4 Pro series, ADI-2 DAC series → lowest latency interfaces for real time internet music rehearsal
Powered by PunBB, supported by Informer Technologies, Inc.