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#ga6c66040d...
== 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