When using a very simple setup like this (the rtp-send is just to keep the null-sink busy) load-module module-alsa-sink device=hw:0,0 sink_name=alsa rate=48000 load-module module-null-sink sink_name=null rate=48000 load-module module-combine sink_name=combined slaves=alsa,null load-module module-rtp-send source=null.monitor And playing (48000 Hz) music on the combined sink, the sample rate to the null sink is severely altered. In the attached piece of log output this can be clearly seen. The rate of the stream for the null-sink varies between 47300 and 48700. I think this is because every time module-combine wakes up to look at the latencies of the slave sink inputs, it finds the null-sink with a different latency. I'm not sure how to fix this, may be some sort of avering (or even a smoother on the latency for each slave sink input) Another way of fixing it (at least getting rid of the symptoms) is by limiting the adjustments module-combine is doing every 10 (by default) seconds. The attached patch does this. The patch is roughly the fix proposed in http://pulseaudio.org/ticket/288 There is other similar code in module-loopback and module-rtp-recv. Should they get the same treatment? Are there any other places? Maarten -------------- next part -------------- A non-text attachment was scrubbed... Name: pulse.log Type: application/octet-stream Size: 5496 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110107/9c66fd88/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-module-combine-limit-the-size-of-the-rate-adjustment.patch Type: application/octet-stream Size: 2483 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110107/9c66fd88/attachment-0001.obj>
