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

Sure, waiting with playing the audio until the buffer has reached the
desired fill is possible. That's a different change though. Adjusting
the sample rate to compensate for missing data is necesary though. You
wouldn't want silence in the middle of the stream because of a bit of
packet loss.

Maarten