rtpjitterbuffer: high CPU usage with low latency audio
Submitted by Petr Kulhavy
Link to original bug (#773770)
Description
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.
Version: 1.9.90