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

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

> 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?

--
Anton Yakovlev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

www.opensynergy.com

Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>
COQOS Hypervisor certified by TÜV SÜD
                [COQOS Hypervisor certified by TÜV SÜD]

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org