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

[Maarten Bosmans]

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>