VBAN protocol questions

[vorosj]

I just discovered that VBAN is supported. :-)

I tried the generator -> VBAN stream. It is working, but stuttering on the local network. The stutter is periodical, and depends on the VBAN network settings (Optimal, fast etc). The slower the setting the more rare the glitches.
The VBAN receptor shows only underrun errors, no missing, corrupt or replaced packets.

I suspect it's buffer underrun on the PC (receiver) side, because maybe the bitrate is a bit slower on the ESP sender side. Maybe the crystal is a little bit under the rated frequency.

Possible, that the PC side VBAN receiver does not have adaptive speed control? :-O
Or it has, but the difference is over it's range?

Or I just misunderstood the situation?

I will measure a clock speed (SPI clock or something) to check, if my ESP32 clock is really slower.

Considering the hw mod of the crystal osc is not easy, maybe a sw trick should help on the ESP sender side? For example repeating a sample after a few thousand samples. Anything is better, then constant stuttering. However, considering the one way protocol, it's manual tuning, not adaptive.

[pschatzmann]

You can use the throttle_correction_ms to fine tune the transmission speed: If you get only underruns you can try to speed up the transmission a bit by increasing the negative value.

[vorosj]

Thank you very much for the fast reply. I missed that setting.
-5 underrun
-6 overload :-)
With "slow" setting on the PC side, 3 sec periodic glitch with the best -6 value.

I dont understand, why the VBAN developer(s) missed an adaptive speed control on the receiver side. Or there is a hidden feature I missed? Hard to believe they missed such an obvious problem. It seems to be a widely used program, the buffer glitches are not present between PC to PC transmissions? They wrote an underrun/overload display (VBANReceptor program), but not a simple adaptive contol? :-O It's so simple on receiver side, check to buffer pointers gap, do something.

A missing adaptive speed control in one way transmission seems to be a brutal error. The simple crystals are accurate in about 1/10000, so - considering a max several thousand samples buffer to keep tolerable latency) there is an inavoidable glitch in about 10 secs at best.
If I am right, it is unsolvable on transmitter side, even a more precise throttle is just resulted in longer glitch period, but - considering the crystal thermal drift - can't eliminate buffer errors.

Maybe a 100usec resolution instead of 1ms improves it a little bit on transmitter side. I'll check the code if I can modify, however it's just symptomatic treatment, not real solution. Maybe simply alternating two throttle values with tunable delays in the main loop should work?

[pschatzmann]

The main thing I disliked was that there are no reasonable codecs supported.

[vorosj]

I am working on a small PC side program that receives the ESP32's VBAN audio and appears to other programs as a virtual mic. The difficulty is the virtual microphone, it's a driver level code, that's what I try to avoid. So I write only the UDP reception, VBAN, and the speed correction part (avoiding buffer overflow), and feed the third party VB-Cable program with the stream. As the input of the virtual cable is a standard Windows speaker, I can select it as output in my code.This way I avoid the hard part, the rest seems to be relative easy, hope it will be ready in a few days.

[vorosj]

Playing with microseconds I was able reach 30...60 seconds without buffer over/under run, however it's useless, because the thermal drift easily destroys my effort. :-)
This way the PC side VBANReceptor, Banana etc programs are useless for device -> PC audio streaming because of the lack of adaptive bitrate control.

// delay
void delaySamples(size_t samples) {
int durationMsEff = millis() - start_time;
int durationToBe = (samples * 1000) / info.sample_rate;
int waitMs = durationToBe - durationMsEff + info.correction_ms;
LOGI("wait: %d", waitMs);
if (waitMs > 0) {
delay(waitMs);
delayMicroseconds(550); ugly hardcoded delay fort test
}

[vorosj]

Using a Python program I tested the VBAN UDP stream of the streams-generator-vban example.
I misunderstood the situation, because so far my test tool was only the VB-Audio program.

I measured the bitrate in Python, and found, that the example program's bitrate varies way too much.

Your intention probaly was, that the throttle setting acts as fine tuning in the 0.1% range. But it's brutal, throttle +-1 resulted in a few percents. And the random deviation is big too, prevents any slow adaptive sync to keep up.

So I think it's a bug in the throttle control. Next I try to fix it.

[vorosj]

I wrote a quick&dirty fix, and now the example is working without buffer under/overflows with either the VB-Audio VBANReceptor or the Python VBAN program.

So I misunderstood the situation in my first comments, the problem was on the ESP side,

[trackme518]

Hi, can you please provide the code? I am dealing with the same problem but I stream from PC to ESP. It gets worse with higher sampling frequencies...

[pschatzmann]

The Throttle implementation has already been corrected and is only use when sending out information...