• State
  • Locked Locked
  • Replies 18 replies
  • Subscribers 98 subscribers
  • Views 4295 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Poor performance streaming audio between two AM335x EVKs

Andrew Ness
Intellectual 450 points
Other Parts Discussed in Thread: WL1837MOD, TMDXEVM3358

I have two AM335x EVKs connected via ethernet to the same router.  

I am trying to stream audio from one EVK to the other using GStreamer, however the receiving side is losing packets and therefore I get choppy audio, even though I can get up to about 600MBps with no packet loss using iperf to test the connection.

If I stream from one EVK to my laptop, there are a couple of lost packets in the beginning but then everything is smooth after that.

Both EVKs can play the audio smoothly when using a local source.

I have also tried streaming to a .wav file on a RAM disk instead of to the audio output but it behaves the same.

Any ideas?

GStreamer server:

gst-launch-1.0 -v filesrc location=dsb.flac ! flacparse ! flacdec  ! rtpgstpay ! udpsink host=192.168.11.202 port=5000

GStreamer client (to audio codec):

gst-launch-1.0 -v udpsrc port=5000 caps='application/x-rtp, media=(string)application, clock-rate=(int)90000, encoding-name=(string)X-GST, caps=(string)"YXVkaW8veC1yYXcsIGZvcm1hdD0oc3RyaW5nKVMyNF8zMkxFLCBsYXlvdXQ9KHN0cmluZylpbnRlcmxlYXZlZCwgcmF0ZT0oaW50KTk2MDAwLCBjaGFubmVscz0oaW50KTIsIGNoYW5uZWwtbWFzaz0oYml0bWFzaykweDAwMDAwMDAwMDAwMDAwMDM\=", capsversion=(string)0, payload=(int)96, ssrc=(uint)3994617306, timestamp-offset=(uint)1574319429, seqnum-offset=(uint)61145' ! rtpjitterbuffer ! rtpgstdepay ! audioconvert ! alsasink

GStreamer client (to .wav file):

gst-launch-1.0 -v udpsrc port=5000 caps='application/x-rtp, media=(string)application, clock-rate=(int)90000, encoding-name=(string)X-GST, caps=(string)"YXVkaW8veC1yYXcsIGZvcm1hdD0oc3RyaW5nKVMyNF8zMkxFLCBsYXlvdXQ9KHN0cmluZylpbnRlcmxlYXZlZCwgcmF0ZT0oaW50KTk2MDAwLCBjaGFubmVscz0oaW50KTIsIGNoYW5uZWwtbWFzaz0oYml0bWFzaykweDAwMDAwMDAwMDAwMDAwMDM\=", capsversion=(string)0, payload=(int)96' ! rtpjitterbuffer ! rtpgstdepay ! audioconvert ! wavenc ! filesink location=/run/out.wav

Note that I took out the ssrc, timestamp-offset, and segnum-offset as a test in both cases but it didn't seem to make a difference (I read somewhere that I should delete them).

Andrew

  • 0
    Intellectual 450 points
    I should add that the CPU usage by the gstreamer process is only about 15-30% on either end and nothing else is running.
  • 0
    Intellectual 450 points

    I should also add that I just tried with the audiotestsrc input and had the same issue, but not as frequently:

    gst-launch-1.0 -v audiotestsrc ! rtpgstpay ! udpsink host=192.168.11.202 port=5000

  • 0 in reply to Andrew Ness
    TI__Guru**** 393215 points
    Hi,

    What Linux version are you using?
  • 0 in reply to Biser Gatchev-XID
    Intellectual 450 points

    I'm using whatever is part of the latest SDK (1.00.03) or whatever it is.  I haven't customized anything yet.

  • 0
    Intellectual 450 points
    Linux am335x-evm 3.14.43-g875c69b #1 Mon Jul 6 16:00:11 EDT 2015 armv7l GNU/Linux

    I booted completely from SD card with boot and root file system on the card to make sure there was nothing else trying to use ethernet. I also killed all unnecessary processes and unloaded unnecessary kernel modules and the problem was the same.
  • 0 in reply to Andrew Ness
    Intellectual 450 points
    With a switch to raw audio vs gstreamer packets over RTP and a bit of buffering, things are much better. But there are still audible dropouts in the audio...even without any errors or warnings from gstreamer. I wonder if it is the audio codec on the eval board dropping packets? Any suggestions on how to debug that?
  • 0 in reply to Andrew Ness
    Intellectual 450 points
    My evidence is that if I stream to disk as a .wav file and then play that back on my laptop, it doesn't have any dropouts now.
  • 0 in reply to Andrew Ness
    TI__Mastermind 40090 points

    Please run ethtool -S eth0 and post the results to this thread. It would be good to isolate if packets are being dropped at the MAC. Do you know what the size of the audio streaming packets is?

    On the last post where you played back the file on the pc without dropouts. I would like to understand more on what you did.  Was gstreamer writing the packets to a file on the evm and the file was copied to the evm and played? Could you also please post the that gstreamer pipeline used for that test?

  • 0 in reply to Schuyler Patton
    Intellectual 450 points

    In the "stream to disk" case, gstreamer was writing the packets to a .wav file on the RAM disk of the EVM.  I then transferred the file to my laptop and played it there and did not hear any dropouts.

    But with my optimized pipelines, it now seems to be working fine over ethernet.  My actual goal is to get it working over Wi-Fi (I have the WL1837MOD on each EVM).  Now that it's working over ethernet, I am less convinced there is a some sort of contention or overflow at the audio codec, but do you think there could be an issue with that?  The Wi-Fi module is hooked up via SDIO while the audio codec is over I2S through the McASP.

    Current pipelines:

    Server: (reading from a flac file on a RAM disk)

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

    Client:

    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

    But when I change the IP to go over Wi-Fi, I get dropped audio.  Once in a while gstreamer will display buffering, which I can understand is due to network issues, but often it doesn't report anything...even with a latency of 5 seconds, which makes me wonder if there is something else.  I've started investigating the Wi-Fi packets with Wireshark but I am new to 802.11.

    Here are the ethtool stats after streaming a 4 minute song over Wi-Fi-: (I rebooted the EVM so they were all 0 just prior)

    root@am335x-evm:~# ethtool -S wlan0
    NIC statistics:
    rx_packets: 109034
    rx_bytes: 158746346
    wep_weak_iv_count: 0
    rx_duplicates: 0
    rx_fragments: 109024
    rx_dropped: 0
    tx_packets: 19
    tx_bytes: 6887
    tx_fragments: 19
    tx_filtered: 0
    tx_retry_failed: 0
    tx_retries: 0
    beacon_loss: 0
    sta_state: 4
    txrate: 150000000
    rxrate: 65000000
    signal: 213
    channel: 0
    noise: 18446744073709551615
    ch_time: 18446744073709551615
    ch_time_busy: 18446744073709551615
    ch_time_ext_busy: 18446744073709551615
    ch_time_rx: 18446744073709551615
    ch_time_tx: 18446744073709551615

    A lot of fragments received I suppose?  I'm not sure what normal is over Wi-Fi

    Andrew

  • 0 in reply to Andrew Ness
    Intellectual 450 points
    I should note that I have created a dedicated Wi-Fi network using hostapd on the server EVK. There is no router involved.
  • 0 in reply to Andrew Ness
    Intellectual 450 points
    Apparently hostapd defaults to no fragmentation and I don't have it specifically turned on in my hostapd.conf

    Andrew
  • 0 in reply to Andrew Ness
    Intellectual 450 points

    I ran the test again streaming from server EVK to my laptop over Wi-Fi. The audio was flawless. The number of fragments seems to be the same though - 100% of packets are going out fragmented. So it seems that is not the issue.  ethtool on the server EVK:

    NIC statistics:
    rx_packets: 1015
    rx_bytes: 89709
    wep_weak_iv_count: 0
    rx_duplicates: 0
    rx_fragments: 1015
    rx_dropped: 0
    tx_packets: 104573
    tx_bytes: 152245788
    tx_fragments: 104573
    tx_filtered: 0
    tx_retry_failed: 0
    tx_retries: 0
    beacon_loss: 0
    sta_state: 0
    txrate: 0
    rxrate: 0
    signal: 0
    channel: 0
    noise: 18446744073709551615
    ch_time: 18446744073709551615
    ch_time_busy: 18446744073709551615
    ch_time_ext_busy: 18446744073709551615
    ch_time_rx: 18446744073709551615
    ch_time_tx: 18446744073709551615

  • 0 in reply to Andrew Ness
    TI__Mastermind 40090 points
    The board you are using is this the am335x evm starter kit? If not could explain the EVK board you are using?

    Since you are seeing success with ethernet now I think you should try the same streaming to disk test earlier that you were doing with the wlan and see if the stream is stored correctly.

    I don't think the audio codec is the issue either.

    Since you are moving to wlan this thread may need to be moved to the wlan forum. I will check into that.
  • 0 in reply to Schuyler Patton
    Intellectual 450 points

    It isn't the starter kit - is the full evaluation kit: TMDXEVM3358.

    I will try the streaming to disk in the morning.

    Thank you for your help btw :-)

    Andrew

  • 0 in reply to Schuyler Patton
    TI__Guru**** 393215 points

    Schuyler Patton said:
    Since you are moving to wlan this thread may need to be moved to the wlan forum. I will check into that.

    WLAN forum is at this location: https://e2e.ti.com/support/wireless_connectivity/f/307 WLAN related questions should be posted there.

  • 0 in reply to Biser Gatchev-XID
    Intellectual 450 points
    Streaming via Wi-Fi to a .wav on a RAM disk seems to be working fine - I don't hear any glitches when I transfer the .wav to my laptop and listen to it.

    Even resampling the audio down to 8k and streaming that over Wi-Fi to the board and playing it while streaming has glitches...so I'm not sure that it's a Wi-Fi specific issue, but I will start a thread over there to see what those guys think.

    Andrew
  • 0 in reply to Andrew Ness
    Intellectual 450 points
    I've stripped away some layers and am having what may be the related, underlying problem. Please see my new post: e2e.ti.com/.../455637