• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 427 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.

dm368 CPU overloads when streaming audio in rtp

Guillaume Frigon
Prodigy 90 points

Hi,

I am trying to use gstreamer to stream audio over network, using RTP. This is done on the DM368 evaluation board. When monitoring the CPU load, I see that it is overloaded (around 99-100%) all the time.

I am using the following pipeline to do so:

gst-launch -v &> output5.log gstrtpbin name=rtpbin \
    alsasrc ! queue ! audioconvert ! TIAudenc1 codecName=aaclcenc engineName=codecServer ! dmaiperf print-arm-load=true ! rtpmp4apay ! rtpbin.send_rtp_sink_1                                             \
        rtpbin.send_rtp_src_1 ! udpsink port=5002 host=$DEST ts-offset=$AOFFSET name=artpsink                                                 \
        rtpbin.send_rtcp_src_1 ! udpsink port=5003 host=$DEST sync=false async=false name=artcpsink                                               \
      udpsrc port=5007 name=artpsrc ! rtpbin.recv_rtcp_sink_1

I have tried streaming via RTP and the CPU load is around 10%. I have also tried using the audio codec and sinking it to a file. The CPU load is then around 1-2%.

Is there a reason why the CPU is loaded that way. Is this an issue with my pipeline or a driver issue?

  • 0
    Prodigy 90 points

    After some tests, the issue seemed to be due to a bad control of the audio sampling rate. By not specifying the sample rate, the driver seemed to be trying to sample as fast as possible, which caused the CPU to overload. By specifying the alsasrc src pad to use to audio/x-raw-int, endianness=1234, signed=true, width=16, depth=16, rate=44100, channels=2, the issue was solved.

    The resulting pipeline is as follows:

    gst-launch -v &> output5.log gstrtpbin name=rtpbin \
        alsasrc ! queue ! audio/x-raw-int, endianness=1234, signed=true, width=16, depth=16, rate=44100, channels=2 ! TIAudenc1 codecName=aaclcenc engineName=codecServer ! dmaiperf print-arm-load=true ! rtpmp4apay ! rtpbin.send_rtp_sink_1                                             \
            rtpbin.send_rtp_src_1 ! udpsink port=5002 host=$DEST ts-offset=$AOFFSET name=artpsink                                                 \
            rtpbin.send_rtcp_src_1 ! udpsink port=5003 host=$DEST sync=false async=false name=artcpsink                                               \
          udpsrc port=5007 name=artpsrc ! rtpbin.recv_rtcp_sink_1

    Doing so, the CPU load is still around 50% which could be acceptable. Is there a way to reduce the load even more? Is the TIAudenc1  being processed in the ARM or the Co-processor? Are the buffers from the alsasrc being copied and if so, is there a way to avoid that (equivalent of the always-copy=FALSE in v4l2src)?