[alsa-devel] Fixing snd_pcm_indirect_playback_transfer to support rewinds?

[Floris Bos]

On 01/02/2018 02:49 PM, Takashi Iwai wrote:
>
>> It seems it is simply denying rewinds instead of making them work?
>> Isn't there any way to make them work, instead of disabling
>> functionality userspace seems to be expecting to have?
> The rewind can't work with the indirect PCM mode due to its nature.
> In the indirect PCM operation, the data has been already copied, thus
> you can't go back beyond the point.

Ah, didn't know it consumed all data right away inside the function.
The construct with sw_ready/hw_ready/hw_queue_size variables gave me the 
impression it could also only process a part and leave the rest for a 
next call.


BTW another thing that I noticed, is that it currently is only possible 
for a sound driver to report either success or failure from the ack 
callback.
While the userspace documentation seems to suggest that partial success 
-in which a lower number of frames than requested is rewinded- is also a 
possibility.

https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga6c66040dbe01797379436fdf36268fec

==
Returns:
a positive number for actual displacement otherwise a negative error code
==



>
> In general, the application can't expect that rewind always works on
> such a device.  That said, it's rather a bug of PulseAudio, I'd say.
>
> Maybe an easy workaround would be to disable the timer-based mode on
> PA, e.g. by adding SNDRV_PCM_INFO_BATCH flag to the PCM stream, a
> patch like below.  You'd need a similar change for the downstream
> drivers.

Will have a look at that later when I have more time.



Yours sincerely,

Floris Bos