[alsa-devel] Master Plan on rewinding

[Tanu Kaskinen]

On Sun, 2014-09-07 at 21:16 +0600, Alexander E. Patrakov wrote:
> === On non-rewindability of the rate plugin ===
> 
> I intend to write a rewindable resampler eventually, but don't have time 
> now. I understand that it is an important task, but issues below (and 
> the dayjob which you can change by offering me a new one) have higher 
> priority for me. However, I want everyone to understand the following 
> point now:
> 
> "The resampler has to be written from scratch for the reasons explained 
> in http://permalink.gmane.org/gmane.linux.alsa.devel/122179 , and 
> similar arguments apply to all other kinds of sound processing code that 
> needs history."
> 
> For PulseAudio, it is also needed to figure out the desired interaction 
> between variable rate and rewindability. Should rewinding other than 
> "discard everything completely" be allowed at all on variable rate 
> streams when the rewind crosses the sample rate change point? I.e., 
> write 100 samples, change rate, write 50 samples, rewind 100 samples, 
> what should be the resulting rate? Should we special-case small changes 
> vs big ones?

This last paragraph isn't related to the rate plugin, right? So you're
talking about PulseAudio internals only? If so, perhaps the best
approach would be to make the current stream buffer contents
non-rewindable when a rate change occurs, at least until someone points
out a real use case where it is important to be able to rewind past rate
change points in the buffer. Without any example use cases, I don't feel
qualified to answer the question what should happen if a rewind crosses
a rate change point (or possibly several!).

Another question is that should we do something to previously buffered
stream data when the rate changes. If the audio rate changes completely,
e.g. from 44.1 kHz to 8 kHz, any previously buffered audio was probably
meant to be played at 44.1 kH, but with the current code it will be
played at 8 kHz. I don't know if there are any applications that (ab)use
the dynamic rate feature this way, though. Maybe we could just document
that the dynamic rate feature is only meant for small adjustments.

-- 
Tanu