[pulseaudio-tickets] [PulseAudio] #288: Smooth rate variation in module-combine

[PulseAudio]

#288: Smooth rate variation in module-combine
--------------------------+-------------------------------------------------
  Reporter:  Chimrod      |       Owner:  mkbosmans       
      Type:  enhancement  |      Status:  new             
 Milestone:               |   Component:  module-combine-*
Resolution:               |    Keywords:                  
--------------------------+-------------------------------------------------
Changes (by mkbosmans):

  * owner:  lennart => mkbosmans


Comment:

 I also see problems like this when using module-combine. In my case it's
 with an alsa sink and a null sink (of which the monitor is used by rtp-
 send) as slaves.

 I'd say the solution is using longer adjust_time, like 100 seconds. Is
 there any reason why that doesn't work in your particular setup? Surely
 the clocks of the two PCs involved drift apart by a factor of more than
 1.2?

 To comment on Lennarts post:
 an adjustment of 1.01 is certainly not a very small rate change.
 Resampling from 48000 to 47500 is very much audible. (and quite annoying
 when listening to music)

 The main change of the patch (as I see it) is instead of limiting how much
 the slave stream rate can differ from the base_rate (of the combined
 sink), there is a maximum on how fast the rate of a slave can change (i.e.
 comparing the new rate to the actual_rate)

 There is certainly value in that, but a proper patch should also account
 for other settings of adjust_time.

 By the way, I have a feeling that the wild variations in rates of the sink
 have nothing to do with deviating clocks (at least in my case), but more
 with the (more or less random) fill-state of the buffer at the moment
 module-combine wakes up to check on slave latencies.

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