On 13. 01. 22 14:45, Takashi Iwai wrote:
Also ideally, there may be a check in hw_params, if parameters
(buffers) are changed, but the implementation is not so easy. Maybe we
can allow OPEN ->
PREPARE transition for this case, so the applications may just restart
the streaming in the most light way.
Hmm. Reading more about those restrictions and requirements, I feel
that this might be better implemented in the gadget driver side
locally at first. Basically we can handle similarly: add a new local
flag, set it at the stream stop, and return an error at prepare until
hw_params gets reconfigured. This might be even smaller changes?
Pavel reported that stop to SETUP is not enough for sox, but it's true that
the driver may fail in the prepare() callback until the standard stream
operation is not recovered. I think that sox is trying to recover and it
succeeds - then the I/O timeout occurs.
Ref:
https://lore.kernel.org/alsa-devel/9635d70f-dc12-f9ed-29f5-ce34a1d4b112@xxxxxxxxxxx/
The gadget driver (drivers/usb/gadget/function/u_audio.c) has empty prepare
callback at the moment.
Pavel, could you try to add the no-stream flag management to the gadget driver
and return an error in the prepare callback in this case?
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
