Re: [virtio-dev] Request for a new device number for a virtio-audio device.

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]

On Fri, May 10, 2019 at 05:13:26PM +0000, Anton Yakovlev wrote:
> > Shared memory isn't a native concept to VIRTIO.  The device and the
> > driver don't assume shared memory access in the general case (i.e.
> > virtqueue buffers could even be copied and virtio-blk, virtio-net, etc
> > would still work!).
> >
> > There is currently a spec extension on the mailing list to add Shared
> > Memory Resources to VIRTIO and new device types will use it.  However, I
> > don't think this is necessary for this use case.
> 
> Yes, we are awared about VIRTIO and shared memory relationships. Our original propose was to support classic way of communications by default. And, thanks to your comments, it can be further improved.
> 
> But there's one issue. An audio device is a real-time device. It has explicit hard deadline. And there're many factors helping an audio device to fail to meet the deadline due to virtualization overhead. And in that sense a virtual audio device differs from each and every other virtual devices. If a block device becomes slower - not a big deal, if a network device becomes slower - not a big deal, if a GPU device starts to skip frames - not very nice, but also not a big deal. But if an audio device starts to skip frames - it's a big problem, and device is nonfunctional as a matter of fact. Good audio device implementation must met two criterias:
> 
> 1. Low latency
> 2. No frame dropping at all
> 
> All I want to say is that any queue-based approach can not guaranty correct functionality to an audio device for all possible use cases. Because a queue has its natural limitations: either in terms of additional latency due to queue notifications, or due to queue limited size. And an audio device eventually will hit one of them for some application. It means, we can not support some cases, which works pretty fine in native operating systems. But such limitations are artificial ones due, again, using a queue for data transfers. In case of shared memory such limitations are just gone.
> 
> So, our proposal is to support classic way of communications by default and introduce shared memory based approach as either non-standard extension or part of future VIRTIO device types. And switch to this mode where it's possible or make sense. Like, all modern type-2 hypervisors usually have no problems with sharing memory between guest and host, so why not provide to user high quality virtual audio device?

virtqueues offer reliable delivery, so #2 isn't an issue.

Real-time is achievable and can be done with low latency.  Make the
receiver a real-time thread that polls the vring periodically (based on
the latency/buffer size requirement).  The vring supports lock-free
access so this is perfect for real-time.

When I say "receiver" I mean the driver's capture and device's playback
components.  Both of them have real-time requirements.

Does this approach meet your requirements?

If not, please explain the shared memory approach and how it is better.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]