[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 brian):

 Replying to [comment:3 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.

 Ahhh.  Right, I did misunderstand then.

 > 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.

 Ahhh.  Yes, indeed.

 > 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)

 So if pavucontrol could request the other end of the tunnel to just send
 at 8kHz (or less?  how high does the sample rate really have to be for
 simply measuring peaks) that's already 1/5th of a typical 44.1kHz stream.

 > 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

 Yeah.

 > - 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.

 Sending the same stream more than once, at different rates seems wasteful.
 I liked Tanuk's idea that there can be multiple subscribers to a stream
 and the rate it's sent at is the highest rate requested among all of the
 subscribers.

 > 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.

 Fair enough.

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