This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Glitches streaming audio between two AM335x EVM boards

Other Parts Discussed in Thread: WL1837MOD

I am working on a solution for streaming audio over Wi-Fi.  I'm evaluating the WL1837MOD and the AM335x processors based on TI's Streaming Audio Reference Design.

I have three AM335x EVM boards and am using GStreamer.  I am using the latest SDK - version 1.00.00.03.

The problem is that I'm getting glitches/dropouts in the streaming audio while listening via the on board headphone output.

I was directed to this forum from the guys over in the Sitara Processors Forum.  I initially posted there as I was having some issues just over ethernet, however with some pipeline optimization and buffering, it is now working smoothly over ethernet.

I am using one EVM as the server, creating a Wi-Fi network using hostapd - there is no router involved.  I'm using the best channel I can find at 5GHz.  I am using another EVM as the client (and have tried a third EVM as a client to make sure it wasn't just this particular device).  Using iperf, I can get up to 100Mbps over the Wi-Fi link sending UDP packets.

There are four scenarios where it is working fine:

  1. Stream from server EVM to client EVM over ethernet, playing back via on board headphone output.
  2. Stream from server EVM to laptop over Wi-Fi.
  3. Stream from server EVM to client EVM over Wi-Fi, saving the data to a .wav file on the local RAM disk, transferring it to my laptop, and playing it back there.
  4. Stream from server EVM to server EVM over localhost, playing back via on board headphone output (only uses ~50% CPU, so not over doing it)

I am streaming a 96k, 24 bit, 2 channel flac file.  I have resampled it down to 8k, and the problem persists.  So I'm wondering if it is a bus contention issue or some other type of issue when using Wi-Fi and the EVM's on board audio codec (connected via I2S and the McASP) simultaneously.

Gstreamer does not indicate any buffering or packet loss/order problems when this occurs (it did before I got the buffering set up etc).  

Even if I set the buffer to 5 seconds it behaves the same.

My pipelines are as follows:

Server:

gst-launch-1.0 -v filesrc location=/run/dsb.flac ! flacparse ! flacdec ! audioconvert ! rtpL24pay ! udpsink host=10.192.0.100 port=5000

Client (streaming to on board audio codec):

gst-launch-1.0 -v --gst-debug=udpsrc:5 --gst-debug=rtpL24depay:4 --gst-debug=rtpjitterbuffer:4 udpsrc port=5000 caps="application/x-rtp, media=(string)audio, clock-rate=(int)96000, encoding-name=(string)L24, encoding-params=(string)2, channels=(int)2, payload=(int)96" ! rtpjitterbuffer mode=2 latency=1000 ! rtpL24depay ! audioconvert ! alsasink

Client (streaming to .wav on RAM disk):

gst-launch-1.0 -v --gst-debug=udpsrc:5 --gst-debug=rtpL24depay:4 --gst-debug=rtpjitterbuffer:4 udpsrc port=5000 caps="application/x-rtp, media=(string)audio, clock-rate=(int)96000, encoding-name=(string)L24, encoding-params=(string)2, channels=(int)2, payload=(int)96" ! rtpjitterbuffer mode=2 latency=1000 ! rtpL24depay ! audioconvert ! wavenc ! filesink location=/run/out.wav

Any suggestions?

Andrew