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

[Maarten Bosmans]

2011/1/11 pl bossart <bossart.nospam at gmail.com>:
>> 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.
>
> Any idea what the sample rate drops linearly in the initial part?
> Maybe we ought to prevent SRC adjustments until there's enough history
> to make such changes?
> -Pierre

Thats because initially the buffer with audio from the RTP stream only
contains about 270 ms worth of data. To get this up to the desired
(hardcoded) value of 500ms, the sink-input reading from this buffer
has to be slowed down a bit. To get it up to 500 in about half a
minute would require the sample rate to be around 47300 Hz, but
instead of jumping directly to this value, the rate is gradually
decreased a factor 0.998 to avoid audible artifacts. This lead to a
wedge in sample rate and a nice S-shaped curve in buffer latency.

The adjustment should not be delayed, because the low buffer should be
filled as soon as possible, to reduce risk of underrun. Also the
estimated "real" sample rate (not shown in the graph) is already
accurately determined very soon. In my case the RTP stream clocks in
at 48006 Hz.

Maarten