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
