[alsa-devel] On non-rewindability of resamplers
Alexander E. Patrakov
patrakov at gmail.com
Fri Apr 25 16:09:26 CEST 2014
25.04.2014 12:19, David Henningsson wrote:
> I understand that you have a mathematically perfect approach to this, as
> well as other algorithms. This would indeed be the best goal, but given
> an imperfect world, where we're forced to choose between
> 1) no rewinding at all
> 2) imperfect rewinding in the sense that it sometimes can produce
> hearable artifacts
> ...I'm not sure 1) is always the right choice...
Understood. But IMHO (2) with a warning would be better than the current
situation of (2) without any indication of the problem.
>> int snd_pcm_hw_params_is_seekable(const snd_pcm_hw_params_t *params);
>> Check if the device fully supports rewinds and forwards.
>> params Configuration space
>> Return values:
>> 0 The whole plugin chain is not guaranteed to support arbitrary
>> rewinds and forwards.
>> 1 The whole plugin chain is guaranteed, under all remaining
>> configurations in the configuration space, to support any rewinds and
>> forwards that don't move the application pointer through the hardware
>> If this function is called when there is more than one configuration
>> exists in the configuration set (e.g. when the rate is not fixed), it
>> may return pessimistic results.
> I wonder if this is flexible enough. I think it would be not too
> uncommon for hardware drivers to e g transfer data to the hardware one
> period at a time. Hence what would make sense to rewind could be
> everything but the current period. A similar approach could potentially
> be done with resamplers (save state data every period so you can rewind
> correctly to exactly those points but nowhere else).
> This would be good to indicate somehow. I e, I'd like to see
> snd_pcm_rewindable take into account how much actually makes sense to
> rewind, taking DMA buffer sizes and other things into account where
> appropriate. Today, we add our own margin of 1.33 ms in PulseAudio
> because (if my understanding is correct) "some DMAs don't like us
> writing exactly the block it's busy transferring", but it would be
> better if this was indicated by ALSA.
This looks like two valid feature requests. Regarding the limited
flexibility, this can be solved by returning a bitmask of rewind-related
limitations, but the current hw_params API doesn't have any functions
that return bitmasks. Instead, for each new problem, a new function is
created. So it may make sense to create more than one function. However,
I am afraid to create a duplicate of an existing function. Does anyone
know whether the "must not rewind to the current period" limitation is
the same as already indicated by snd_pcm_hw_params_get_fifo_size() or
snd_pcm_hw_params_is_batch() or snd_pcm_hw_params_is_block_transfer()?
Of course, these limitations should be honoured by snd_pcm_rewindable().
As for the applicability of limiting the rewinds to the period
boundaries (where the resampler state is saved), then we have already
discussed something similar in person during LinuxCon Europe 2013 in the
context of PulseAudio and IIR filters. If access to the original samples
since the beginning of that period is not lost, then we can rewind to
the period boundary earlier than needed, then restore the state and
reapply the samples between that period boundary and the point we
actually wanted to reply to. So the net effect would be "can rewind to
anything except the currently playing period". OTOH I know another
approach that would make only a few samples non-rewindable (i.e. will
look similar to the 1.33ms limitation), and I will probably try to
implement it on my vacation as a new proof-of-concept library.
Alexander E. Patrakov
More information about the Alsa-devel