2011/1/7 pl bossart <bossart.nospam at gmail.com>: > Hi Maarten, > >> 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 > > Yes the same issue happens with the loopback when capturing data from > BT or some RTP source. The latency on a standard ALSA device varies > less wildly but the adjustments are still arguable in terms of audio > quality. > I posted a rate adjustment as well a while ago which was never merged, > but that's not enough. We'd need some averaging to prevent jittery > adjustments. It's been on my TODO list for some time but if you want > to go ahead feel free :-) > -Pierre I've taken my previous approach a bit further and applied it to module-rtp-recv this time. The end goal is still to apply it to all three modules. I think this solves 2 bugs against module-rtp-recv, so when I'm finished the final patch should close three bugs. Just like the previous patch this limits the size of the rate changes to inaudible jumps. Also when the rate is close enough (10Hz) to the sink rate, it is set exactly to the sink rate. In my case the computer sending the rtp stream was clocking at 48006, so this approach resulted in the rate on the receiving end cycling between 48000, 48000, 480018. This noticably reduced CPU consumption 2/3 of the time. The main improvement of this patch is the calculation of the new rate. It only is three lines of code, but without explanation of how I derived it, I think it would seem a bit magic. So there is a pretty verbose explanation above it, fully leveraging the blessings of unicode. The only part I am not sure about is the request_rewing hunk of the patch. For me it behaves better when not requesting a maximum rewind, but using the value of underrun_for. I got this from module-loopback but don't quite understand whether it is correct or not. If it is, it should probably be applied to more places where nbytes is set to 0 currently. Maarten -------------- next part -------------- A non-text attachment was scrubbed... Name: module-rtp-recv-2.patch Type: application/octet-stream Size: 7092 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110110/6ad1ffd1/attachment.obj>
