Sending TDM samples over UDP

[nick]

Hi,
I want to send TDM audio samples to a PC using UDP. I'm using the xCore-200 Multichannel board directly connected with an ethernet cable to the PC.
I'm currently using the lib_xtcp (ver 6.1.0) and lib_i2s (ver 2.3.0).

The communication between the TDM and UDP tasks, and the buffers are similar to the AVB application note (AN00203): there are 2 buffers (which are swapped as soon as one is full) and I send through the tasks the address of the buffers (not the buffers themselves).
I managed to make it work with 8 channels (1 TDM8 input line) buffering 4 samples for each channel.
So the length of the buffer sent through UDP was: 8channels*4samples = 32 int32_t

Then I tried to increase the number of channels to 16 (2 TDM8 input line) keeping the number of buffered samples to 4.
After some debugging I noticed that the TDM task filled the buffer quicker than the UDP task was able to send the other. I tried to reduce the number of samples buffered to 2 (in this way I was sending the same amount of data of the 8 channel configuration) but without success.
I think that the only difference between the 2 configurations (keeping the amount of sent data equal) is the number of TDM callbacks.
Can this affect the performance of the UDP task or am I not seeing the real problem?

I know that is difficult to understand the structure of the code without seeing it so I can share with you the parts you want to see to better understand.

Thank you

[CousinItt]

What's your audio sample rate? Also, what bit rate is your ethernet link configured for?

[nick]

I'm working at 48 kHz and the ethernet is configured for 1 Gbps.

[akp]

What are you using for UDP? lib_xtcp?

[nick]

Yes, I'm using lib_xtcp ver 6.1.0

[akp]

I suspect that might be a little slow. If you build the udp packets by handcoding that will be faster. Run it like the avb talker code

[ozel]

I've had the same experience, lib_xtcp is not suitable for streaming data over UDP (neither over TCP, of course), at least if it should be a couple of 10s of MBits. Maybe the new FreeRTOS stack could do that better, but probably not (yet). I would also advise to make your own UDP packet builder. Especially if the packet size can be kept constant, you can pre-calculate most of the headers and only one of the checksums is really mandatory anyway. The more you have control over the receiver, the easier it is to optimize for throughput obviously. I can share some code if needed, meant to put it on github at some point anyway. Don't forget to buffer your data in a FIFO thread before building the UDP packets, like in the AVB implementation as akp mentioned.

In my specific situation, it was even beneficial to got back to 100 Mbit and disable some parts in the gigabit MAC to gain a lower number and thus faster logical cores for the FIFO buffering. There's a thread on downgrading the gigabit MAC to 100 Mbit for freeing some resources.

[nick]

Thanks for your answers.
I'm not an expert of UDP, so I'll try to figure out how to create the packets.
If you can share code, it'd be great! Let me know please.

Currently the buffers are the same as the AVB code, and also the organisation of the tasks. So I don't think that this will be a problem after the optimisation of the UDP.

[CousinItt]

See the example code in AN00199 for constructing arp and ping response packets. UDP packet construction can follow a similar pattern.

Use wireshark or similar to show how your packets look. It's a big help with spotting formatting errors.

[nick]

AN00199 has been very useful.
I managed to make it work creating the UDP packets.
Thanks to everyone!