Re: [PATCH] virtio-sound: add latency_bytes definition

[Anton Yakovlev <anton.yakovlev@opensynergy.com>]

Hi Matias,


On 07.11.2023 19:46, Matias Ezequiel Vara Larsen wrote:
> Ping Anton.
>
> Thanks, Matias.
>
> On Thu, Oct 5, 2023 at 11:41âAM Matias Ezequiel Vara Larsen
> <mvaralar@redhat.com> wrote:
> > This commit aims at providing a better definition of latency_bytes. To
> > do so, this commit defines latency_bytes as is defined in Crosvm.
> >
> > Signed-off-by: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
> > ---
> >   device-types/sound/description.tex | 5 ++++-
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/device-types/sound/description.tex b/device-types/sound/description.tex
> > index 54c9c8e..1349765 100644
> > --- a/device-types/sound/description.tex
> > +++ b/device-types/sound/description.tex
> > @@ -694,7 +694,10 @@ \subsubsection{PCM I/O Messages}\label{sec:Device Types / Sound Device / Device
> >   \begin{description}
> >   \item[\field{status}] contains VIRTIO_SND_S_OK if an operation is successful,
> >   and VIRTIO_SND_S_IO_ERR otherwise.
> > -\item[\field{latency_bytes}] indicates the current device latency.
> > +\item[\field{latency_bytes}] indicates the current device latency. For
> > +playback, this is the amount of bytes that must be consumed before
> > +the current request can be played. For capture, this is the latency in terms of
> > +bytes that the capture buffer was recorded.
> >   \end{description}

Yes, this field definitely needs some clarification.

If you think about it, from the point of view of the application in the guest,
the size of the current latency is the current contents of the buffer. I.e.
exactly what you added to the description, but without taking into account the
value of this field.

In the current Linux driver implementation, this "latency_bytes" value is
saved to the "delay" field, which is then passed to user space. And this
"delay", as I understand it, indicates an additional delay caused by the
specifics of the hardware.

And it turns out that the latency_bytes field either should indicate such an
additional delay (for example, caused by the specific implementation of the
backend on the device side), or does not make sense, since the current latency
value is already known a priori. What do you think?


> >   Since all buffers in the queue (with one exception) should be of the size
> > --
> > 2.41.0

--
Anton Yakovlev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin