On 20.09.2023 00:52, Michael S. Tsirkin wrote:
On Tue, Sep 19, 2023 at 04:18:57PM +0200, Matias Ezequiel Vara Larsen wrote:
On Tue, Sep 19, 2023 at 05:43:56AM -0400, Michael S. Tsirkin wrote:
On Wed, Sep 13, 2023 at 05:04:24PM +0200, Matias Ezequiel Vara Larsen wrote:
This email is to report a behavior of the Linux virtio-sound driver that
looks like it is not conforming to the VirtIO specification. The kernel
driver is moving buffers from the used ring to the available ring
without knowing if the content has been updated from the user. If the
device picks up buffers from the available ring just after it is
notified, it happens that the content is old.
Then, what happens, exactly? Do things still work?
We are currently developing a vhost-user backend for virtio-sound and
what happens is that if the backend implementation decides to copy the
content of a buffer from a request that just arrived to the available
ring, it gets the old content thus reproducing some sections two times.
For example, we observe that when issuing `aplay FrontLeft.wav`, we hear
`Front, front left...`. To fix this issue, our current implementation
delays reading from guest memory just until the audio engine requires.
However, the first implementation shall also work since it is conforming
to the specification.
Sounds like it. How hard is it to change the behaviour though?
Does it involve changing userspace?
Maybe we need to fix the spec after all...
Fixing the problem Matias described only requires changes to the driver. But
we will need to restrict applications from mmap()'ing the buffer. Applications
will be able to read/write frames only through ioctl() requests.
I think we could expand the sound specification to add support for shared
memory. Then it should be possible to implement mmap() support on top of it.
Senior Software Engineer
Rotherstr. 20, 10245 Berlin
Virtualization mailing list