[pulseaudio-tickets] [PulseAudio] #807: RTP modules do not allow the null sink to suspend when monitoring it using lots of CPU

[PulseAudio]

#807: RTP modules do not allow the null sink to suspend when monitoring it using
lots of CPU
--------------------------+-------------------------------------------------
  Reporter:  psihozefir   |       Owner:  lennart                     
      Type:  enhancement  |      Status:  new                         
 Milestone:               |   Component:  module-rtp-*                
Resolution:               |    Keywords:  CPU frequency, drain battery
--------------------------+-------------------------------------------------

Comment(by psihozefir):

 I was reading your post over and over again, and I'm trying to understand
 as much as I can from it. Since the RTP transmision involves a client and
 a server, I guess "the server" is the one listening from connections on
 the network and that outputs the audio stream to the physical device not
 the one serving the audio stream over the network, right? In this sense,
 my laptop is a client and my desktop is a server.

 htop or top on my laptop shows the CPU stays below 10% at all times,
 except when I'm compiling something, when it can be seen the CPU's usage
 is 100%. The problem is, the kernel's conservative CPU frequency governor
 decides to "clock" the CPU at its highest available freqency when the RTP
 client and the RTP monitor are running (that is, without an increase in
 CPU's usage as shown by top or other CPU monitoring program).

 So... "using lots of CPU" is not quite correct in my opinion. This would
 be correct if you would get the same results as when running the following
 bash script:
 while true; do echo >/dev/null; done

-- 
Ticket URL: <http://pulseaudio.org/ticket/807#comment:7>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server