You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Ethernet audio library ready to beta test
- Thread starter palmerr
- Start date
- Status
- Not open for further replies.
yes, AES67 would be nice - but it's a lot of work and there's not much in the public domain (other than the ESP32 code you mentionhttps://github.com/ndac-todoroki/esp32_aes67_sender - and he seems to have abandoned it because the packet rate was unachievable, evern with a processor dedicated to WiFi.). This leaves a lot of the heavy lifting still to be done - e.g. QoS - for a proper AES 67 implementation.
I'm thinking of aligning with a simpler format in the short term - a protocol called VBAN developed by VB-Audio for their range of (largely free) windows audio programs. https://vb-audio.com/Voicemeeter/vban.htm
Probably next will be to finish the update of the 8 x 8 channel audio board (a T4 update on Paul's original design). I've got RevB boards sitting on the bench waiting to be loaded and tested for N&D. Rev A proved the design.
After that, VBAN on the current WIZNET hardware, followed by a port to the T4.1 native ethernet (again - all the bits sitting here waiting for some time to put it all together).
Finally, something like AES67 to make a nice, compliant overall package!
Sadly, I'm distracted by other projects at the moment - like work!
Anyway, keep in touch, because I will get back to this project. It was driven by my band's need for better, personalised, foldback: 8 channel unit plugged into the desk, individual 2 channel units using Paul's SGTL5000 audio boards, transport over ethernet.
I'm thinking of aligning with a simpler format in the short term - a protocol called VBAN developed by VB-Audio for their range of (largely free) windows audio programs. https://vb-audio.com/Voicemeeter/vban.htm
Probably next will be to finish the update of the 8 x 8 channel audio board (a T4 update on Paul's original design). I've got RevB boards sitting on the bench waiting to be loaded and tested for N&D. Rev A proved the design.
After that, VBAN on the current WIZNET hardware, followed by a port to the T4.1 native ethernet (again - all the bits sitting here waiting for some time to put it all together).
Finally, something like AES67 to make a nice, compliant overall package!
Sadly, I'm distracted by other projects at the moment - like work!
Anyway, keep in touch, because I will get back to this project. It was driven by my band's need for better, personalised, foldback: 8 channel unit plugged into the desk, individual 2 channel units using Paul's SGTL5000 audio boards, transport over ethernet.
For the teensy, I think QOS is just a matter of tagging outgoing packets. ??
PTPv2 (for clock sync) is a big requirement for AES67, but this is hugely beneficial when you are dealing with a variety of audio sources. VBAN uses a non-scalable "receiver needs to infer an exact rate and adjust". But not clear that there is any viable way for a teensy 4 to dynamically adjust its audio clock rate.
PTPv2 (for clock sync) is a big requirement for AES67, but this is hugely beneficial when you are dealing with a variety of audio sources. VBAN uses a non-scalable "receiver needs to infer an exact rate and adjust". But not clear that there is any viable way for a teensy 4 to dynamically adjust its audio clock rate.
True on both counts.
With AES 67, there's not much point in the Teensy tagging packets if they are not properly dealt with across the network. For a private "audio only" network, particularly if it has 1GB capable switches, that's not usually a problem, as congestion is unlikely with reasonable audio streams.
You have noted the transcoding limitation of VBAN, as it's a protocol, not an audio engine. It is common with AES67, where the host also needs to do any transcoding. However you can simply make sure all the endpoints are talking the same bit depth and bitrate for most practical projects. The reason for VBAN: It's very close to my current UDP protocol, so we get significantly increased utility for very little work.
Building an proper AES67-compliant stack requires a nearly-complete re-work of my code (a new project), and some of the stack's components are simply not there for a Teensy. If someone else creates the components, like PTPv2 clock, (and the Teensy Native Ethernet folks are doing a great job on the network core) I'll hook them in. I agree that an ethernet-transported world clock would be a wonderful thing.
Another key limitation with my implementation is that it ignores packet loss (out of sequence packets don't happen in most LANs). Fixing dropped packets is a trade-off with latency, as there needs to be sufficient latency in the chain for a dropped packet to be re-inserted without interrupting the audio. This would push out the number of audio buffers required by several times, and with Paul's reasonable choice of 128 sample buffers (2.9mS per buffer), latency grows quicwith additional queue buffers to the point where the set-up becomes unusable for live sound.
Thanks for the lively discussion, this thread has been quiet for a while - mainly because I've been working on other things.
With AES 67, there's not much point in the Teensy tagging packets if they are not properly dealt with across the network. For a private "audio only" network, particularly if it has 1GB capable switches, that's not usually a problem, as congestion is unlikely with reasonable audio streams.
You have noted the transcoding limitation of VBAN, as it's a protocol, not an audio engine. It is common with AES67, where the host also needs to do any transcoding. However you can simply make sure all the endpoints are talking the same bit depth and bitrate for most practical projects. The reason for VBAN: It's very close to my current UDP protocol, so we get significantly increased utility for very little work.
Building an proper AES67-compliant stack requires a nearly-complete re-work of my code (a new project), and some of the stack's components are simply not there for a Teensy. If someone else creates the components, like PTPv2 clock, (and the Teensy Native Ethernet folks are doing a great job on the network core) I'll hook them in. I agree that an ethernet-transported world clock would be a wonderful thing.
Another key limitation with my implementation is that it ignores packet loss (out of sequence packets don't happen in most LANs). Fixing dropped packets is a trade-off with latency, as there needs to be sufficient latency in the chain for a dropped packet to be re-inserted without interrupting the audio. This would push out the number of audio buffers required by several times, and with Paul's reasonable choice of 128 sample buffers (2.9mS per buffer), latency grows quicwith additional queue buffers to the point where the set-up becomes unusable for live sound.
Thanks for the lively discussion, this thread has been quiet for a while - mainly because I've been working on other things.
Hi Richard,
I have been trying to get the ether-audio working with your examples on a recent version of Arduino / TeensyDuino (1.8.13).
The simple TX example work fine on a T4.0 (checked with python PC app), but i'm having mixed succes with the simple RX.
On a Teensy 3.2, i get output on pwm and DAC, but since i want to run eventually on Teensy4 and i have only a T4 audio board, i moved on to that.
On the T4, the program will not see the stream, unless i also enable SPDIF. I do however not see any output on pin 4 (pwm1) like i see on the T3.
AudioOutputSPDIF spdif1;
AudioOutputPWM pwm1;
AudioConnection patchCord4(net_in1, 0, pwm1, 0);
AudioControlSGTL5000 sgtl5000_1;
If i try to get output through the SGTL5000, the program will hold at the sgtl5000_1.enable(); line.
AudioOutputI2S audioOutput;
AudioConnection patchCord1(net_in1, 0, audioOutput, 0);
AudioConnection patchCord2(net_in1, 0, audioOutput, 1); // always fails at sgtl5000_1.enable()
If i patch a sine to the I2S instead of net_in1, then the program runs as expected (although no stream is output, but only locally generated sine is heard).
Can you help me with a known good configuration for Teensy4 + T4 audio board?
I have been trying to get the ether-audio working with your examples on a recent version of Arduino / TeensyDuino (1.8.13).
The simple TX example work fine on a T4.0 (checked with python PC app), but i'm having mixed succes with the simple RX.
On a Teensy 3.2, i get output on pwm and DAC, but since i want to run eventually on Teensy4 and i have only a T4 audio board, i moved on to that.
On the T4, the program will not see the stream, unless i also enable SPDIF. I do however not see any output on pin 4 (pwm1) like i see on the T3.
AudioOutputSPDIF spdif1;
AudioOutputPWM pwm1;
AudioConnection patchCord4(net_in1, 0, pwm1, 0);
AudioControlSGTL5000 sgtl5000_1;
If i try to get output through the SGTL5000, the program will hold at the sgtl5000_1.enable(); line.
AudioOutputI2S audioOutput;
AudioConnection patchCord1(net_in1, 0, audioOutput, 0);
AudioConnection patchCord2(net_in1, 0, audioOutput, 1); // always fails at sgtl5000_1.enable()
If i patch a sine to the I2S instead of net_in1, then the program runs as expected (although no stream is output, but only locally generated sine is heard).
Can you help me with a known good configuration for Teensy4 + T4 audio board?
Sorry, I haven't tested the Ethernet functions ***AT ALL*** on the T4 (and particularly not on a T4.1's native ethernet port). As there are different branches of code all through the libraries for the T4, it's likely that there may be something that's significantly different enough to break the Ethernet code, even if you're using the WIZNET adapters. I'm hoping to get to this sometime, but other urgent projects have got in the way.
Good to hear, though that the simple TX does function.
As for the PWM - it appears I've left a bunch of digitalWrite(4, x) diagnostics in the code (e.g. control_ethernet line 153), oops!
You'll need to get inside the code to see where the packets are jammed on the simple RX. The key points are where it checks if there is a packet available (control_ethernet line 260). The actual stream processing is pretty standard (apart from the queues used to manage asynchronous packets), so it's unlikely that there's a foul up there on a T4 if a good packet was received. Turning on the CE_SERIAL_DEBUG or IN_ETH_SERIAL_DEBUG flags should help.
The other possibility is that your LAN is flooding the input and blocks are being dropped by the WIZNET. Looking back at the code, it appears that I didn't put a preamble into the packet structure, so the code assumes all incoming packets are net_audio (I built the code on an offline gigabit switch with several T3s.) When I get to V2 of the library, I'm going to align the UDP structure with the VBAN protocol, as it provides a ready bridge for PC-Teensy network audio. I've tested 4 channels @48kHz over WiFi on an ESP32 relatively successfully (some lost packets), so wired ethernet should be more reliable.
Ethernet doesn't take update_responsibility (and neither does the PWM on the T4 like it does on the T3), so not surprised to find that you need to also enable SPDIF (which does). However the SGTL5000 should do the job - as long as its begin() function and the I2S init() functions have been run in setup().
The order of object creation is important. The order the objects are constructed sets the order in which updates() are processed, and should follow the flow of audio across the signal chain. Have a look at the code the System Design Tool creates - it gets the order right. In your case, this issue is unlikely to affect things, but worth a check.
Hope all this helps,
Richard
Good to hear, though that the simple TX does function.
As for the PWM - it appears I've left a bunch of digitalWrite(4, x) diagnostics in the code (e.g. control_ethernet line 153), oops!
You'll need to get inside the code to see where the packets are jammed on the simple RX. The key points are where it checks if there is a packet available (control_ethernet line 260). The actual stream processing is pretty standard (apart from the queues used to manage asynchronous packets), so it's unlikely that there's a foul up there on a T4 if a good packet was received. Turning on the CE_SERIAL_DEBUG or IN_ETH_SERIAL_DEBUG flags should help.
The other possibility is that your LAN is flooding the input and blocks are being dropped by the WIZNET. Looking back at the code, it appears that I didn't put a preamble into the packet structure, so the code assumes all incoming packets are net_audio (I built the code on an offline gigabit switch with several T3s.) When I get to V2 of the library, I'm going to align the UDP structure with the VBAN protocol, as it provides a ready bridge for PC-Teensy network audio. I've tested 4 channels @48kHz over WiFi on an ESP32 relatively successfully (some lost packets), so wired ethernet should be more reliable.
Ethernet doesn't take update_responsibility (and neither does the PWM on the T4 like it does on the T3), so not surprised to find that you need to also enable SPDIF (which does). However the SGTL5000 should do the job - as long as its begin() function and the I2S init() functions have been run in setup().
The order of object creation is important. The order the objects are constructed sets the order in which updates() are processed, and should follow the flow of audio across the signal chain. Have a look at the code the System Design Tool creates - it gets the order right. In your case, this issue is unlikely to affect things, but worth a check.
Hope all this helps,
Richard
Last edited:
- Status
- Not open for further replies.