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