[pulseaudio-tickets] [PulseAudio] #897: include vumeter samples in the remote protocol

[PulseAudio]

#897: include vumeter samples in the remote protocol
--------------------------+-------------------------------------------------
  Reporter:  brian        |       Owner:  lennart
      Type:  enhancement  |      Status:  new    
 Milestone:               |   Component:  daemon 
Resolution:               |    Keywords:         
--------------------------+-------------------------------------------------

Comment(by coling):

 Sorry I think you misunderstood. I was just pointing out the
 '''existing''' flag. I'm just saying that I'm not sure '''it''' cuts down
 on data much - not that only sending peak data vs. full stream would cut
 down on data much.

 As Tanuk has said via the mailing list, the problem really lies in how
 tunnels work.

 I could also do some stuff in PA to really cut down on the use of the
 monitor streams - At present there are four tabs which show VU meters, but
 you can only see one at a time. Therefore we can easily "cork" the streams
 that are not visible. This will cut down on the amount of traffic it
 subsequently generates. Also, as tunnels are involved here, even if the
 PEAK_DETECT flag is used, the tunnel itself still uses a fixed rate. The
 actual tunnel is opaque to pavucontrol - it's just another sink. Therefore
 the problem is that we request the data from the Tunnel Sink at the lower
 25Hz rate, but for that Tinnel Sink to get the data it has to transfer it
 over the wire at the rate the tunnel operates (i.e. 44.1kHz) and then down
 sample it to 25kHz to feed it to our peak detector... obviously this is
 suboptimal but that really need to be worked on in the Tunnel Sink
 implementation - perhaps add the ability to send different data rates at
 the same time or to allow for dynamic switching of sample rates in a
 tunnel.

 All of these things will help alleviate the situation and I'm not against
 doing any of those. The thing I'm not sure of is doing some thing totally
 custom for peak detection. For one thing, it'll be a lot more work than
 the other solutions above and I'm not really sure how much practical
 advantage it would have above a solution that just fixes the problems
 mentioned above and discussed on the mailing list.

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