Re: virtio-sound: release control request clarification

[Manos Pitsidianakis <manos.pitsidianakis@linaro.org>]

On Tue, 17 Oct 2023 at 18:19, Matias Ezequiel Vara Larsen
<mvaralar@redhat.com> wrote:
>
> Hello,
>
> This email is to clarify the VirtIO specification regarding the RELEASE
> control request. Section 5.14.6.6.5.1 [1] states the following device
> requirements for the RELEASE control request:
> 1. The device MUST complete all pending I/O messages for the specified
> stream ID.
> 2. The device MUST NOT complete the control request while there are
> pending I/O messages for the specified stream ID.
>
> The 1) requirement does not indicate what "complete" means. Does it mean
> that the pending I/O messages in the tx queue shall be outputted in the
> host, i.e., consumed by the audio backend? Or, completion means simply
> to put the requests in the used-ring without consuming them?

It means the latter. At no point is the host's consumption of audio
data mentioned except for implicit or explicit period notifications.

>
> Regarding 2), I interpret it as "the device shall wait until all I/O
> messages are proceeded to complete the RELEASE control request".

Possible state transitions to RELEASE state are from PREPARE and STOP,
which neither are associated with active I/O in the streams.
The correct interpretation is "Do not reply to the control request if
you have pending I/O messages for this stream ID".

> Currently, the kernel driver seems not expecting such a delay when the
> RELEASE command is sent. If I understand correctly, the kernel driver
> first sends the RELEASE command and waits a fixed amount of time until
> the device can process it. Then, the driver waits a fixed amount of time
> until all pending IO messages are completed. If the device follows the
> specification and waits until all messages IO are completed to issue the
> completion of the RELEASE command, the kernel driver may timeout. The
> time to complete N IO messages in the TX queue could be proportional
> with the number of pending messages.
>
> In our device implementation [2], RELEASE is handled as follows:
> - Drop all messages in the TX queue without outputting in the host.
> - Complete the RELEASE control request.
>
> This seems to be working, however, I can observe that sometimes there
> are still requests in the TX queue when we get RELEASE. Those requests
> are never reproduced in the host.

My guess is this is because of the guest alsa doing prebuffering, not
that the host is supposed to handle those I/O messages.

--
Manos