[pulseaudio-discuss] Rethinking rate adjustments [was: Re: [PATCH] module-combine: limit the size of the rate adjustments]
bossart.nospam at gmail.com
Tue Jan 11 13:12:26 PST 2011
>> 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?
> 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.
More information about the pulseaudio-discuss