New client for Teensy Audio

[palmerr23]

Vincent,

I'm updating my ethernet connector (https://github.com/palmerr23/ether_audio) for the Teensy Audio suite (https://github.com/PaulStoffregen/Audio) to include VBAN compliance.

The VBAN documentation is excellent, however I noticed that the more recent VB-Audio products have VBAN error correction.

Do I need my code to respond to some sort of a packet resend request or is the error correction all managed on the receiving client?

Any advice you can give about lost packet reconstruction and handling slight differences in world clock speeds would be appreciated!

For single packet losses, I could re-create the missing packet by cross-fading between the two packets either side.

For clock speed differences, I would create a similar buffer and insert it when the incoming buffer is getting low, and substitute the cross-faded packet for the two packets either side if the incoming buffer is getting close to overflowing.

Richard

[Vincent Burel]

Thanks for your interest in VBAN protocol

REM: There is no packet resend or ACK process (transmitter is simply sending packet when audio stack provides buffer).
Our different applications are including a SRC to adjust the VBAN sample rate to the current audio stack sample rate.

but for a same sample rate on VBAN and Audio device, you can basically get 2x kinds of problems on receiver side:
1- UNDERRUN: You need a packet to feed the audio stack but the VBAN has no packet ready, then repeat the previous packet or imagine something better.
2- OVERLOAD: VBAN wants to provide a packet but the audio stack is full, then drop it or mix it or imagine something better.

Clock difference is not another problem, this is simply producing the 2 possible problem above.

With WIFI, the main problem is not the clock but the speed variation of the network infra structure (on WIFI side, on router side, on device ethernet stack), that's why we provide a NETWORK QUALITY parameter on our receiver/receptor to adjust the buffering behind (see documentation).
Big buffering (SLOW) can cope to huge elasticity of the packet flow, but will generate delay/latency (> 100ms) ... Small buffering (OPTIMAL or FAST) will need a more regular packet flow and will generate a small latency (< 20 ms).

Hope it helps.

[palmerr23]

Thanks Vincent,

I thought that would be the case with dropped packets, underruns and overloads. I will take one of the approaches you suggest.

The application I have in mind needs low latency, so I'm staying with wired Ethernet for now. Initial testing: I can receive 14 channels on a Teensy 4.1 before it starts to drop packets.

My tests on WiFi (using a simpler block protocol) suggest that for more than 2 channels, the implicit error correction (lost packet resend) below the UDP layer make big buffers necessary as packets arrive with substantially different network delays.

[Vincent Burel]

REM: low latency will be anyway around 256 or 512 samples buffer at the end because Voicemeeter or other applications are using such regular buffer size for audio device management (128 sometimes, 64 more rarely). And for the current protocol implementation, you may consider getting VBAN packet from a 5 to 20ms audio buffering process (meaning you will have to cope to burst of 5 to 20 ms VBAN packet anyway).

For example Matrix Coconut implements VBAN 64 and 128 channels now, So there is only 32 to 2 samples in the VBAN packet (to stay belaow 1436 bytes), so you obviously get a burst of several packets to fit a 256 sample audio buffering on receptor side. I mean the receptor must be able to manage such latency , even if managing audio in real time with a much more small latency.

For low latency RT system (let say < 1 ms audio buffering), possibly based on specific hardware, i've planned the AOIP sub protocol (that will be the same than the current PCM) but will notify the fact the receptor / transmitter will use low latency buffer with the capability to send VBAN packet in time. This is made for possible hardware unit we could imagine later.

WIFI infrastructure is very complex and i recommend to fulfill the VBAN packet as much as possible, to limit the number of packet sent.

[palmerr23]

Thanks.

By low latency I'm meaning low enough for live sound use (<15mS), rather than really low latency (1-2mS), so I think things will be OK for output from a DAW and point to point communications.

Yesterday's test was between two wired points on my home LAN (which includes WiFi). On an isolated network I'm receiving 4 x 8 channel streams from Voicemeeter with no dropped packets on the Teensy 4.1 hardware. This is without any packet processing, so capacity may be less when the full implementation is done.

BTW, I found an ESP8266 implementation of Receptor online (https://github.com/flyingKenny/VBAN-Rec ... SP8266-I2S), so I may update it to work on a Pico W when I'm done. I think 2 channels should be OK over WiFi so it could be a workable ear monitor solution.

With dropped packets, I'm thinking of synthesizing a packet to put between the two received packets. Reverse the samples in each packet and cross fade. This should provide a smooth transition between the two received packets. The processing overhead might be too high for large packets of float samples, but should be manageable for integers. If not, I'll just duplicate a packet as you suggested.

[palmerr23]

BTW the four streams were 8 channels of 96kHz, 24 bit PCM each.

[palmerr23]

When I'm converting audio streams to VBAN packets should I create VBAN packets with different numbers of samples or always keep to t he same number of samples?

E.g. 8 x 128 sample (PCM16) buffers = 2048 samples = 4096 bytes
Packet 1 = 8 x 89 samples
Packet 2 = 8 x 39 samples

OR

Packet 1 = 8 x 64 samples
Packet 2 = 8 x 64 samples

The second option seems safer!

[Vincent Burel]

The important point is to fulfill packet as much as possible to avoid a too big number of packet.

if packet have same or different sizes is not so important.