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

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

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

After careful consideration, I think polling mode should make it possible. Like, using dedicated "data" queue per stream in polling mode (multiplexing is not an option, since it reduces queue throughput in proportion to the number of multiplexed streams). How to describe it in specification?


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