VBAN Stream on internet

[AtmanActive]

... but of course if the network is getting a 500ms or even 200ms delay on packet delivery, this could cut our VBAN Stream (that's why most streaming platform are usually using several second of pre-buffering....

That's exactly where I see the problem here.
We can either choose AoIP apps that have several seconds of pre-buffering, or we can choose VBAN with 100ms max.
What is stopping us from having everything in between?

[AtmanActive]

Reading the specifications here, on page 13, I can see the network buffer sizes implementation.

In the interest of clarity, transparency and portability, I would like to suggest to avoid labeling and standardizing presets for those. I believe it would be much more useful for everyone to be able to choose buffer sizes, as numbers, starting with 16 and then doubling up: 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536. In that way, users are free to experiment and find the right buffer size for their application, be it LAN 10G-to-10G, or internet connections half across the world.

As it is proposed now, the real-world numbers are hidden behind cryptic labels ("Optimal", "Fast", "Slow"...), which, in my humble opinion, just serves to confuse everyone.

Also, the proposed minimum right now is 512, which effectively means that really low latencies will never be achievable. Again, I believe it is not up to us to pre-determine that. Who knows what future might bring. 10G networks? 100G ethernet? 64 cores threadrippers?

Protocol itself should stay open and widely adjustable so it can adopt to all possible usage scenarios of both tomorrow and yesteryear.

Thanks.

[Vincent Burel]

well, 512 buffer size work perfect on local wired network. and VBAN AOIP is planned to work with 1 to 16 samples buffer (transporting up to 256 channels).

Also the buffering is not the problem (VBAN cannot make bigger packet than 256 samples anyway) , but the PRE-BUFFERING can be not enough on some internet connection sure!.

That's why we are preparing a POC with a server in France to test a new service called VBAN-LINK ... if you are intrested in i will invite you to test it as well and see if it improve the things for your workflow... and we will be able to measure precisely the problem on our side...

[AtmanActive]

Yes, sure. Thank you. I sent you a Private Message.

[AtmanActive]

well, 512 buffer size work perfect on local wired network.

Ah, but the question is what does "perfect" mean and in what context. Are we comparing it to analog cables? Or is our baseline Zoom or similar?

My perspective is: as low as possible latency, given what hardware would allow for, for usage in live music applications. For musicians to be able to play together, maximum acceptable latency is around 10ms. Even that feels uncomfortable for some musicians. Perfect values would be 5ms and lower.

I just did a local test on my local LAN network like this:

Code: Select all

Computer 1: [Mic->Centrance Mic Port->Voicemeeter Potato->VBAN]
-> 1Gbps Ethernet Switch ->
Computer 2: [VBAN->Voicemeeter Potato->Focusrite Scarlett 6i6 2nd Gen->Speakers]

Then, I recorded the sound with my phone, via it's built in mic. The sound I was making was snapping my fingers, so that my phone could capture both the direct sound from my fingers and the sound from the speakers. Then I imported that recording into Reaper, and with zoom-in and cutting, found how far apart in time those two sounds are, and the result is:
31ms
Now, for someone that doesn't really care, that could sound perfect.
But, for a musician, that's bad. That's unusable in live situations.
Sampling frequency was 44100 Hz, throughout. My Centrance Mic Port's ASIO was set to 45 samples. My Focusrite Scarlett 6i6 2nd Gen's ASIO was set to 16 samples.
Hence, that leaves me with 30ms of latency introduced by VBAN alone.
And my question here is: why?
If I have a sufficient hardware, fast CPUs, good ASIO drivers, 1Gbps networks, then, why can't I go lower than 30ms latency with VBAN?
And, in 10 years from now? Even if we will all have 128 cores of CPUs and 10Gbps networks, VBAN will still enforce 30ms latency on us?

What I am trying to explain and show here is that presuming that something is good enough, simply because our experience leads us to believe it is, doesn't make a good, future proof standard that could be used in many different situations. By standardizing VBAN buffering to 5 predefined values we are actually limiting VBAN to only a small subset of all global possible usage scenarios. Just imagine if your local ASIO driver had "Low", "Mid" and "Fast" buffer options, how limiting that would be. Saying that VBAN's buffer sizes of "Optimal", "Fast", "Medium", "Slow" and "Very Slow" is good enough for everyone is the same as the famous saying that "640KB is enough for everyone". And, going forward, it will just make VBAN unusable for some applications, which will force users to search for alternate solutions, and will limit VBAN in what it can do, and, slowly but surely, it will be left behind.

[Vincent Burel]

yes, we know that current VBAN implementation is not for live music.
we consider 256 or 512 sample as the best compromise on wire PC network to manage audio (for broadcaster, movie watching etc.. ),
because basically Windows is not able to do better.

You can simply compute by yourself, even with a 256 buffer audio engine

MIC AD conversion: one buffer = 256
MIC AUDIO interface : one buffer 256
VBAN SEND : 256 samples (Optimal mode)
Ethernet wire 1 GHz : < 0.1ms (not significant)
VBAN RCV: 256 samples (Optimal mode)
Focusrite output audio interface : 256 samples
DA conversion: 256 samples

total: 6x 256 samples = 31.25 ms (it can be a little better because VBAN use 256 buffers in most of cases and AD/DA is usually done in less than 2 ms... but it 's a realistic evaluation).

If you want to do better, you will have to consider more expensive software and hardware solution.

[AtmanActive]

Hi Vincent,

Thank you very much for your time and your explanations.
I do believe your opinions, evaluations and calculations are coming from your rich experience and windows audio expertise.
However, if you don't mind, I would like to challenge your views here.
If you do mind, just let me know and I'll bugger off .

If I understand your explanation correctly, it is Voicemeeter's internal audio engine's buffer that can't work with buffers smaller than 256 samples, right?
Hence, no matter if I set my ASIO devices to 16 samples each (or whatever low value), Voicemeeter/VBAN will still process everything in 256 chunks and will therefore introduce 31ms of latency, one way or the other. Correct me if I'm wrong here.

But then again, how are DAWs, like Reaper, for example, capable of syncing to ASIO driver's buffers and working in lower-than-256-samples chunks?

On the network side of things, we are talking about UDP packets, right? Even if we would send just one stereo sample in each packet's payload, that would be 28 (header) + 4 (16bit stereo) = 32 bytes. If we presume half of effective line speed, that's 500Mbps / ( 32 * 8 ) = 1.9 million packets per second - i.e. way, way more than needed 44100.

If we would be talking about a proprietary software here, like Voicemeeter, for example, then, I wouldn't have much to add; it is your software designed with your specific usage case in mind. But, since we are talking about an open source protocol here, called VBAN, then, I do believe and would like to express that the specification for buffers, on page 13 is an error in judgement, since both low-latency local AND long-distance on the internet usage cases can't really work. VBAN lowest buffer of 512 is too big for local low-latency, and it's highest buffer of 8192 is too small for long-distance internet.

I'll continue my quest for low latency ASIO+ETH solutions and will post my findings here.

Thanks.

[Vincent Burel]

If I understand your explanation correctly, it is Voicemeeter's internal audio engine's buffer that can't work with buffers smaller than 256 samples, right?

No, Voicemeeter can work With Any ASIO buffering. even 32 samples with famous Focusrite ASIO driver.
but i say that below 256 samples (below 5 ms) Windows is not able to guarantee a stable stream.

ASIO driver working with less than 128 sample buffer, do not work stable or are hacking the audio callback by calling it twice or more in the same time slot. This way to manage ASIO driver is disturbing our virtual ASIO driver (because striclty synchronized on double buffering ASIO principle) .
More info on this subject here: viewtopic.php?f=11&t=506

I'll continue my quest for low latency ASIO+ETH solutions and will post my findings here.

Good luck, and keep in mind for internet that 300 km of cable = 1ms of latency (without counting router latency).

[AtmanActive]

ASIO driver working with less than 128 sample buffer, do not work stable or are hacking the audio callback by calling it twice or more in the same time slot. This way to manage ASIO driver is disturbing our virtual ASIO driver (because striclty synchronized on double buffering ASIO principle)

Are you trying to tell me that I should test with two RME HDSPe AIOs on PCIex on each machine and will get different results?

[AtmanActive]

... and keep in mind for internet that 300 km of cable = 1ms of latency (without counting router latency).

Is this the same latency that ICMP ping would show? Of course, ping shows Round Trip Time, which is there and back actually.