2011/1/10 Maarten Bosmans <mkbosmans at gmail.com>: > 2011/1/7 pl bossart <bossart.nospam at gmail.com>: >> 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. Just to show some of the results of the changes, attached is a graph of latency and sample rate for module-rtp-recv. The first graph shows the current behaviour. This is the ever increasing sample rate, as described in http://pulseaudio.org/ticket/670 The second graph is with the old algorithm to determine the sink input sample rate, but with a limit on how big the steps of the adjusments are. This is already a lot better. (note the wildly different scales of the first graph compared to the second and third) The latency is kept around the target of 500 ms, but it is not very stable yet. The third shows the new algorithm. Doesn't it look pretty? The event halfway (after two minutes of playing) is change of song. Apparantly this introduces some extra samples in the RTP stream, but the algorithms deals nicely with that. The new algorithm does not seem to work well for module-combine, so as it stands I would only do the clamping of the rate adjustments there and not the algorithm change, just like the patch I send earlier in this thread. I still have to look into module-loopback, but I guess it will be similar to either module-rtp-recv or module-combine. Maarten -------------- next part -------------- A non-text attachment was scrubbed... Name: pulse-rtp-latency.pdf Type: application/pdf Size: 56368 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110111/3bee2bde/attachment.pdf>
