rtpjitterbuffer: high CPU usage with low latency audio
Submitted by Petr Kulhavy
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.
gst-launch-1.0 udpsrc retrieve-sender-address=false uri="udp://188.8.131.52: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%
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.