[alsa-devel] Master Plan on rewinding

[Alexander E. Patrakov]

08.09.2014 00:38, Tanu Kaskinen wrote:
> 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?

Right.

>  So you're
> talking about PulseAudio internals only?

Yes, in the last paragraph 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.

Thanks for the feedback. Let's see if others say anything else on this 
topic.

-- 
Alexander E. Patrakov