On Thu, 2013-07-11 at 10:01 +0200, Peter Meerwald wrote: > Hello, > > > that there is no reuse of the leftover samples across the rewind. This > > also applies to your wrapper, otherwise the following happens: > > pulseaudio pushes some samples to the resampler, resampler (or > > wrapper) remembers the last few of the fed-in samples because they > > would be needed for the next portion, but then pulseaudio feeds in a > > completely unrelated block of audio instead of that portion because of > > the rewind. > > thank you for pointing this out > > so if there is a rewind, reset() must be called on the resampler pa_resampler_reset() will be called on rewinds anyway, that's no problem. If you just drop the buffered leftover data on reset(), that's trivial to implement. There are a few issues in the current resampler code. Your code doesn't necessarily need to solve them, but it's good to be aware of them. The first is that I believe simple reset results in some inaccuracy at least for the next sample that the resampler produces, because a reset means that the resampler pretends that the previous audio was all silence, which is not true. That said, we have been doing this forever, and nobody has complained, and I would guess that the error is rarely audible. The second issue is that if the resampler does any buffering (like the wrapper that you perhaps plan to do, or swr_convert()), and the buffered data is dropped on rewind, the dropped data should be accounted for in the next component in the rewind chain - the dropped data should be sort of pushed back to where it originally came from, otherwise that data is completely lost, so the audio skips (very little, but perhaps audibly). The third issue is that if the resampler does any buffering, that affects the latency, and that is not currently taken into account in the latency calculations. The added latency is perhaps small enough not to matter at all. -- Tanu
