[pulseaudio-discuss] [PATCH] module-combine: limit the size of the rate adjustments

[Maarten Bosmans]

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>