[Bug 773770] New: rtpjitterbuffer: high CPU usage with low latency audio

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=773770

            Bug ID: 773770
           Summary: rtpjitterbuffer: high CPU usage with low latency audio
    Classification: Platform
           Product: GStreamer
           Version: 1.9.90
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: brain at jikos.cz
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

rtpjitterbuffer in combination with udpsrc seems to be very CPU demanding with
low latency audio stream. With 1kpps audio stream rtpjitterbuffer alone
requires roughly 20-25% CPU time on 500MHz Cortex A7.

Usecase 1:
gst-launch-1.0 udpsrc  retrieve-sender-address=false uri="udp://224.1.2.3:5004"
caps="application/x-rtp,media=(string)audio,encoding-name=(string)L24,clock-rate=(int)48000,encoding-params=(string)2,channels=(int)2"
! rtpjitterbuffer latency=10000 ! fakesink

In this usecase two things can be observed:
* while buffering (the first 10 seconds) the CPU usage is 25% (for udpsrc)
* then the CPU jumps briefly to 60% and stabilizes at about 45%

Usecase 2:
gst-launch-1.0 audiotestsrc is-live=true wave=sine samplesperbuffer=48 !
"audio/x-raw,format=(string)S24BE,rate=(int)48000,channels=(int)2,channel-mask=(int)0x3"
! rtpL24pay ! rtpjitterbuffer latency=10000  ! fakesink

In the second use case the CPU usage while buffering is 4-5% and after
buffering is done 7-9%. 

I would expect similar CPU usage (5-8%) also on top of UDP source (how ever
udpsrc currently inefficient is, see bug 772841), but 20% CPU is clearly too
much.

I was investigating the logs for the usual suspects like extra buffer copy, but
have not found any. The only clear difference I could see between the two logs
is that in Usecase 2 the packets are processed immediately, whereas in Usecase
1 many timers are processed per packet. However it is hard to debug that way
since the debug messages introduce a significant extra lag, which disturbs the
measurement.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.