BlueCat Connector Latency 1024 samples (Can I do better?)
-
- KVRAF
- 3220 posts since 23 Dec, 2002
I have a local area network (2 computers only) that is running though a Netgear 1200AC RS120 router. The Machines are physically next to each other and the router. Both computers have 1gb network adapters and are tuned for audio performance. During testing I turned off all firewall protection (not my preference) .
I am sending audio only from one machine to the the other via the latest Connector software on the network settings. The best latency that I can achieve via Connector without frequent dropouts is 1024 samples. Both machines can handle 128 sample buffers with ease but I am using 256 buffers on the audio cards and switching to 512 buffers on both computers audio cards to test and that made no difference.
Both computers are running at a 48k sample rate. I have tried all buffer settings, auto settings, manually setting packet sizes, and the suggested multiples. I have also adjusted the quality of the audio stream to the lowest lossy settings and still 1024 is the best I can achieve without frequent drop outs.
Are there any other optimizations I can try? Should I spend money on a switch instead of a router? Are my network adapters too slow? Any help is appreciated.
Again both computers are highly optimized for audio with 56 cores on one machine 28 cores on the other. RME Raydat audio interface on one and Expert Sleepers Es-9 on the other. These are usually very capable machines.
I am sending audio only from one machine to the the other via the latest Connector software on the network settings. The best latency that I can achieve via Connector without frequent dropouts is 1024 samples. Both machines can handle 128 sample buffers with ease but I am using 256 buffers on the audio cards and switching to 512 buffers on both computers audio cards to test and that made no difference.
Both computers are running at a 48k sample rate. I have tried all buffer settings, auto settings, manually setting packet sizes, and the suggested multiples. I have also adjusted the quality of the audio stream to the lowest lossy settings and still 1024 is the best I can achieve without frequent drop outs.
Are there any other optimizations I can try? Should I spend money on a switch instead of a router? Are my network adapters too slow? Any help is appreciated.
Again both computers are highly optimized for audio with 56 cores on one machine 28 cores on the other. RME Raydat audio interface on one and Expert Sleepers Es-9 on the other. These are usually very capable machines.
- KVRAF
- 7030 posts since 19 Apr, 2002 from Utah
I'd be interested in knowing this information as well! 
For those using this software, what latency are you experiencing?
For those using this software, what latency are you experiencing?
Vendor‑Dependent Copy Protection: Customers lose. Pirates win.
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
-
- KVRAF
- Topic Starter
- 3220 posts since 23 Dec, 2002
I am hoping that after this weekend we’ll see a response.
audiojunkie wrote: Thu Jan 02, 2025 7:04 pm I'd be interested in knowing this information as well!
For those using this software, what latency are you experiencing?
-
- KVRAF
- Topic Starter
- 3220 posts since 23 Dec, 2002
So to answer my own question. Yes, I can do better. My router lan ports were limited to 100 mbps and I replaced my router with one that had 1 gbps ports. I am able to achieve 384 samples for about 8 ms latency streaming one stereo stream. This is between two older X99 machines with relatively low clock speeds . Previously I was getting 1024 samples without drop outs (or 21 ms). Both of the PCs are highly optimized.
I am going to test it with one machine being a MacBook Pro M1 running the same session and audio card to see if clock speed and or platform matters. I am hoping that I can get to 6ms latency without dropouts. Disabling firewalls although not preferred seems to help but I won't be running with those off for obvious reasons.
I am going to test it with one machine being a MacBook Pro M1 running the same session and audio card to see if clock speed and or platform matters. I am hoping that I can get to 6ms latency without dropouts. Disabling firewalls although not preferred seems to help but I won't be running with those off for obvious reasons.
Last edited by Scotty on Tue Jan 07, 2025 4:06 am, edited 2 times in total.
- KVRAF
- 7030 posts since 19 Apr, 2002 from Utah
Thanks for reporting what you've learned! Please keep this thread updated.
This is useful information for me. 
Vendor‑Dependent Copy Protection: Customers lose. Pirates win.
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
-
- KVRAF
- Topic Starter
- 3220 posts since 23 Dec, 2002
I have been able to get a reported latency of 5.8ms . This is with both of my older xeons x99 systems. I set both of my physical interfaces to 128 sample latency. Set the buffers on the receiving Connector VST to 256 samples and that reports just under 6ms latency without drop outs. I have have kept my firewalls turned on. This is sending audio and midi. It is possible to configure the plugin for a round trip for effect inserts and sends which would double the latency I would think but I haven't tested that yet.
I also want to send at least 4 stereo streams without dropouts ideally and will test with that. In my testing I am sending from VCV Rack Pro using their plugin hosting module to Cubase.
I also want to send at least 4 stereo streams without dropouts ideally and will test with that. In my testing I am sending from VCV Rack Pro using their plugin hosting module to Cubase.
audiojunkie wrote: Mon Jan 06, 2025 9:45 pm Thanks for reporting what you've learned! Please keep this thread updated.This is useful information for me.
![]()
- KVRAF
- 7030 posts since 19 Apr, 2002 from Utah
Nice! Please keep reporting your findings. 
Vendor‑Dependent Copy Protection: Customers lose. Pirates win.
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- 6336 posts since 8 Sep, 2004 from Paris (France)
Hi,
Sorry for the delay. You should indeed be able to get much lower latencies than 1024 samples.
For a safe audio stream with low latency, the rule of thumb is to use the same sample rate and buffer settings on both machines (the lowest possible). If one of them can get a lower buffer size with stable audio i/o, you can use it (again, the lower the better, even if different on both machines - they should however be a multiple of each other if possible).
Then on the receiver side, buffering should be set to twice the buffer size of the audio app, and at least the size of the other app's buffer if different (probably a bit more).
On Apple M! macs with RME audio interfaces, we can usually set the audio soundcard buffer to 16 samples without any problem, and in such cases if the network is not busy, we managed to go down to 32 samples buffering in Connector, resulting in a pretty low latency.
BTW the Connector buffer size is not the actual latency (it is usually smaller). The actual latency is between the Connector buffer size (max latency) and the Connector buffer size minus the audio app buffer, if both apps are using the same buffer size:
(network latency on a LAN is definitely negligible here)
The reason is that both interfaces are not synchronized, so audio processing probably occurs at different times on both. Depending on the timing, the actual latency may differ.
Also please be aware that this latency doe snot add to the input latency of your audio interface, as connector sends/receives audio data directly while processing. So both audio interfaces latencies do not add.
I hope this clarifies!
Sorry for the delay. You should indeed be able to get much lower latencies than 1024 samples.
For a safe audio stream with low latency, the rule of thumb is to use the same sample rate and buffer settings on both machines (the lowest possible). If one of them can get a lower buffer size with stable audio i/o, you can use it (again, the lower the better, even if different on both machines - they should however be a multiple of each other if possible).
Then on the receiver side, buffering should be set to twice the buffer size of the audio app, and at least the size of the other app's buffer if different (probably a bit more).
On Apple M! macs with RME audio interfaces, we can usually set the audio soundcard buffer to 16 samples without any problem, and in such cases if the network is not busy, we managed to go down to 32 samples buffering in Connector, resulting in a pretty low latency.
BTW the Connector buffer size is not the actual latency (it is usually smaller). The actual latency is between the Connector buffer size (max latency) and the Connector buffer size minus the audio app buffer, if both apps are using the same buffer size:
Code: Select all
connector_buffer-interface_buffer<=actual latency<=connector_bufferThe reason is that both interfaces are not synchronized, so audio processing probably occurs at different times on both. Depending on the timing, the actual latency may differ.
Also please be aware that this latency doe snot add to the input latency of your audio interface, as connector sends/receives audio data directly while processing. So both audio interfaces latencies do not add.
I hope this clarifies!
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- 6336 posts since 8 Sep, 2004 from Paris (France)
So it's just changing the router that helped? The issue is definitely not the bandwidth, but 100MB routers may indeed have more jitter and gigabit routers may have better clocks.Scotty wrote: Mon Jan 06, 2025 11:38 pm I have been able to get a reported latency of 5.8ms . This is with both of my older xeons x99 systems. I set both of my physical interfaces to 128 sample latency. Set the buffers on the receiving Connector VST to 256 samples and that reports just under 6ms latency without drop outs. I have have kept my firewalls turned on. This is sending audio and midi. It is possible to configure the plugin for a round trip for effect inserts and sends which would double the latency I would think but I haven't tested that yet.
I also want to send at least 4 stereo streams without dropouts ideally and will test with that. In my testing I am sending from VCV Rack Pro using their plugin hosting module to Cubase.
BTW have you tried to turn on audio compression (lossless)? It may also help if the culprit is the network (and not the CPU). It greatly reduces the amount of data streamed on the network.
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- 6336 posts since 8 Sep, 2004 from Paris (France)
For ultra low latency on Mac, if you have issues, (if I remember well) you may want to deactivate the Mac's constant polling on the web for system updates. On some model it completely locks the network interface!Scotty wrote: Mon Jan 06, 2025 8:51 pm I am going to test it with one machine being a MacBook Pro M1 running the same session and audio card to see if clock speed and or platform matters. I am hoping that I can get to 6ms latency without dropouts. Disabling firewalls although not preferred seems to help but I won't be running with those off for obvious reasons.
-
- KVRAF
- Topic Starter
- 3220 posts since 23 Dec, 2002
Yes, just changing the router to the 1gbps ports made the difference here. I use templates to control the variables when testing. I always bring up the same projects and ensuring the audio interfaces are setup with matching settings prior to testing Connector.
UpNp Redirect: No matter the router (I've tried 3 now) I always have to use the uPnP redirect to establish communication between the sending and receiver plugins on the two computers. Is that adding some latency that I can avoid? I am unclear if this should be necessary or desirable. Can you shed more light on this?
I always test with all audio compression options available . There is less drift with lossy options but the dropouts don't stabilize enough to enable going to lower latency settings. I use multiples of the physical buffer settings when testing latency. E.G. The interfaces on both computers are at 128 samples therefore buffers in Connector are set at multiples of this for testing. I also experiment with the packet size on connector in the sending mode although automatic seems to be about the same as setting packet size exactly to the same values as the interface buffer settings.
BlueCat: Thanks for the latency reporting. I can set one of the computers to 32 samples (That is the RME Raydat). I'll test it there. The sending machine is on an Expert Sleepers ES-9 and 128 is about the best I can achieve as my default project is quite large. I will use multiples as your documentation suggests.
Does the software latency increase with more streams that are sent? How does that scale. I am unclear on that?
Are there any other things I can try to get reduced latency in this two computer scenario (sending 1 stereo stream with midi over ethernet) ?
For testing I did the following.
Default Templates: I have default templates for both VCV Rack Pro and Cubase and always bring them up to test to get a baseline with the actual physical audio interfaces and default projects configured the same way each time. VCV Rack Pro (Connector is sending from that app) also has some controls over how the CPU threads are utilized. I have tested those and experienced no significant differences in Connector latency.
Cabling: The cabling stayed the same which is Cat5e cables but I have higher quality and higher rated Cat6 cables coming today. I realize that Cat5e cables have the bandwidth but the cables have been kicking around my spare boxes for years now so I thought I would try that just in case the cables are compromised.
Firewalls and Security: I have tested with and without firewall enabled using Emisoft as my security solution here which for audio has been the lightest computer protection in terms of cpu load . I can enable and disable it or parts of it with a mouse click. So I always test with and without that on both of these computers.
Next Steps.
1. I'll try anything that you suggest.
2. I want to test using Cubase to Cubase on the same two computers just in case VCV Rack Pro which is hosting the BlueCat Connector Plugin isn't ideal for this task.
3. I'll do the Mac testing later as most of the time I am PC to PC.
4. Both computers are highly optimized for audio as described in detail by Pictus in the hardware thread of KVR. I can experiment with the performance settings to give background tasks priority as perhaps network speeds can be enhanced by changing the performance settings to be optimized for background instead of foreground tasks. I'm fishing now though.
UpNp Redirect: No matter the router (I've tried 3 now) I always have to use the uPnP redirect to establish communication between the sending and receiver plugins on the two computers. Is that adding some latency that I can avoid? I am unclear if this should be necessary or desirable. Can you shed more light on this?
I always test with all audio compression options available . There is less drift with lossy options but the dropouts don't stabilize enough to enable going to lower latency settings. I use multiples of the physical buffer settings when testing latency. E.G. The interfaces on both computers are at 128 samples therefore buffers in Connector are set at multiples of this for testing. I also experiment with the packet size on connector in the sending mode although automatic seems to be about the same as setting packet size exactly to the same values as the interface buffer settings.
BlueCat: Thanks for the latency reporting. I can set one of the computers to 32 samples (That is the RME Raydat). I'll test it there. The sending machine is on an Expert Sleepers ES-9 and 128 is about the best I can achieve as my default project is quite large. I will use multiples as your documentation suggests.
Does the software latency increase with more streams that are sent? How does that scale. I am unclear on that?
Are there any other things I can try to get reduced latency in this two computer scenario (sending 1 stereo stream with midi over ethernet) ?
For testing I did the following.
Default Templates: I have default templates for both VCV Rack Pro and Cubase and always bring them up to test to get a baseline with the actual physical audio interfaces and default projects configured the same way each time. VCV Rack Pro (Connector is sending from that app) also has some controls over how the CPU threads are utilized. I have tested those and experienced no significant differences in Connector latency.
Cabling: The cabling stayed the same which is Cat5e cables but I have higher quality and higher rated Cat6 cables coming today. I realize that Cat5e cables have the bandwidth but the cables have been kicking around my spare boxes for years now so I thought I would try that just in case the cables are compromised.
Firewalls and Security: I have tested with and without firewall enabled using Emisoft as my security solution here which for audio has been the lightest computer protection in terms of cpu load . I can enable and disable it or parts of it with a mouse click. So I always test with and without that on both of these computers.
Next Steps.
1. I'll try anything that you suggest.
2. I want to test using Cubase to Cubase on the same two computers just in case VCV Rack Pro which is hosting the BlueCat Connector Plugin isn't ideal for this task.
3. I'll do the Mac testing later as most of the time I am PC to PC.
4. Both computers are highly optimized for audio as described in detail by Pictus in the hardware thread of KVR. I can experiment with the performance settings to give background tasks priority as perhaps network speeds can be enhanced by changing the performance settings to be optimized for background instead of foreground tasks. I'm fishing now though.
Blue Cat Audio wrote: Tue Jan 07, 2025 1:11 pmSo it's just changing the router that helped? The issue is definitely not the bandwidth, but 100MB routers may indeed have more jitter and gigabit routers may have better clocks.Scotty wrote: Mon Jan 06, 2025 11:38 pm I have been able to get a reported latency of 5.8ms . This is with both of my older xeons x99 systems. I set both of my physical interfaces to 128 sample latency. Set the buffers on the receiving Connector VST to 256 samples and that reports just under 6ms latency without drop outs. I have have kept my firewalls turned on. This is sending audio and midi. It is possible to configure the plugin for a round trip for effect inserts and sends which would double the latency I would think but I haven't tested that yet.
I also want to send at least 4 stereo streams without dropouts ideally and will test with that. In my testing I am sending from VCV Rack Pro using their plugin hosting module to Cubase.
BTW have you tried to turn on audio compression (lossless)? It may also help if the culprit is the network (and not the CPU). It greatly reduces the amount of data streamed on the network.
- KVRAF
- 7030 posts since 19 Apr, 2002 from Utah
Thank you for responding, Blue Cat Audio!
I wanted to know this information as well. 
Vendor‑Dependent Copy Protection: Customers lose. Pirates win.
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
-
- KVRAF
- Topic Starter
- 3220 posts since 23 Dec, 2002
-
- KVRAF
- Topic Starter
- 3220 posts since 23 Dec, 2002
-
- KVRAF
- Topic Starter
- 3220 posts since 23 Dec, 2002