Teesny audio over UDP

It all depends on how many channels of audio you want to transfer!

Using the standard 48kHz / 16bit format of the audio library, you would need at least 1MHz bit rate per channel (~768kHz + some overhead for packet framing, start and stop bits, etc).

Paul lists up to 4MHz transfer rates for T3.6, so I'd assume the T4s can handle this, also.

You'd have to re-write the physical layer as UDP/IP is quite different (packet vs stream) from serial. Serial should be fairly easy to work with.

I'd advise providing transmit/receive buffers of at least two full packets, so that you don't have to deal with buffer overruns. And buffers add latency...

see Serial1.addMemoryForRead(buffer, size) https://www.pjrc.com/teensy/td_uart.html

I hope this helps.
 
For starters, I wouldn’t recommend using NativeEthernetUdp for this, due in part to its blocking nature. If you take the time to transfer the code directly to FNET you’ll more than likely have a better time if it is in your UDP read function. Especially once you start doing more than one stream like you plan on doing I don’t believe it will be able to keep up otherwise.

It's been a while since I've updated on this project, however, I thought I'd drop a quick note to say that we did some testing today with about 20 teensy devices over a LAN and the system worked really nicely without lag or latency and at a good quality.

I've not moved across to using FNET directly, however, interesting enough when the system is loaded up it's causing random crashes under load from directly within FNET. The lines from the crashes aren't always the same, but the three below are consistent:
Code:
C:\Program Files (x86)\Arduino\java\bin/C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FNET\src\stack/fnet_mempool.c:220
C:\Program Files (x86)\Arduino\java\bin/C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FNET\src\stack/fnet_mempool.c:154 (discriminator 1)
C:\Program Files (x86)\Arduino\java\bin/C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FNET\src\stack/fnet_checksum.c:136

I'll be investigating this in more detail tomorrow and will report back if there's anything of interest to share. The crashes are seemingly random and seem to be linked to the amount of data being handled by the device. More to follow.
 
The crashes are seemingly random due to what’s causing the crash, from what I’ve been able to find it’s the Ethernet interrupt that causes it. Since you aren’t using FNET directly you should have no problem switching over to QNEthernet and that should fix the problem.
 
Good news that you have sorted the basics and have it working (sort of) over Ethernet.

Were you transferring 20 separate streams, or just broadcasting a single stream to 20 devices?

The non-blocking QNEthernet sounds good, and I might resurrect my audio library ethernet transport layer to take advantage of it. I can think of a host of audio applications, if I can get 8 channels or single independent streams going reliably. 4 was about the maximum using the WizNet chips and a T3.6.
 
Each client can transmit and receive on seven different channels or streams simultaneously in our design. Looking at the CPU and memory consumption I'm pretty confident the 4.1 could handle a lot more than the 7 I'm using. The maximum audio memory used sits between 3 and 4 when under heavy load.
 
The crashes are seemingly random due to what’s causing the crash, from what I’ve been able to find it’s the Ethernet interrupt that causes it. Since you aren’t using FNET directly you should have no problem switching over to QNEthernet and that should fix the problem.

Spot on @vjmuzik. Swapped across to using QNEthernet and ran the system without a single crash during a testing session that latest about 4 hours. Previously we'd been getting 15-20 crashes an hour. Thanks for the steer!
 
Back
Top