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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
