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

[pl bossart]

>> 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.

Couldn't silence be played initially? It seems weird to me to change
the sampling rate to compensate for missing data. Resampling should
compensate for clock drifts.
-Pierre