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

[Marco Martinelli - 13Byte srl <marco@13byte.com>]

Wow, it seems like you guys from opensinergy beat me on time. Nice job, 
congratulations!

Your work is way ahead of mine, so much that I'm thinking of stepping 
aside and letting you do the specifications, while experimenting on my 
code privately just for the fun of it.
Just a couple of questions.
You mentioned that the PoC was tested on Linux and Windows 10. I presume 
these are the guest OSs.
On the host side are you working on qemu or another hypervisor?
Besides contributing to the specifications, will you open source the 
actual implementation?
 From your website I see you work in the automotive business. Will your 
implementation be automotive oriented or general purpose?
My idea was to support the general public and in particular the gamers 
and the musicians with my project. I want to be sure that these 
categories will be supported.
The reason I'm asking these questions is to see if it makes sense for me 
to keep working on this project, perhaps to implement the specifications 
proposed by you, or if you're already taking care of everything I was 
interested in implementing.


Best regards,
Marco


Il 10/05/19 19:13, Anton Yakovlev ha scritto:
>> 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
>


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