Open Mingwang-Li opened 1 year ago
Hi @Mingwang-Li ,
I would separate two topics:
@YanVugenfirer hello! FYI I am in the process of merging a virtio-snd device in upstream QEMU:
https://lore.kernel.org/qemu-devel/cover.1692731646.git.manos.pitsidianakis@linaro.org/
PS: To make an uneducated guess: According to this documentation page, the port-miniport driver model corresponds to ALSA's design, so perhaps a new device driver can take advantage of that and have little glue code.
@epilys nice to meet you!
yes, the moment we will start the work supporting virtio-sound on Windows, miniport driver will be needed.
How are the upstream reviews going?
Progressing steadily, as always there's lots of important work the list and objectively virtio-sound is a low priority :)
@YanVugenfirer nice to meet you!
I am glad to hear that you are working on the Windows driver for virito-snd. As soon as the guest driver is ready, I would start implementing the virtio-snd device for mvisor as a feature requested here (https://github.com/tenclass/mvisor/issues/2).
- Windows driver for virtio-snd. Here we need a really good justification to do it. Basically, MS has universal audio architecture https://en.wikipedia.org/wiki/Universal_Audio_Architecture - which means all audio devices should be "standard" and use MS class driver. So without understanding the usage case, we don't see special reason to do something that cannot be certified.
@YanVugenfirer Isn't the virtio-snd specification based, at least in part, on the Intel High Definition Audio specification, which in turn is part of Microsoft's Universal Audio Architecture? As I understand from this documentation, that was done deliberately, to make it possible to add support for virtio-snd to a unified HDA driver.
Nice to see support for virtio-snd
picking up, both in hypervisors and as a Windows guest driver in addition to the already mainlined Linux driver.
I'm curious about the possible improvements in terms of CPU utilization and latency that a paravirtualized sound driver could offer over an emulated HDA device, or an emulated USB audio device for that matter.
Thanks for your efforts, everyone.
@volkertb
WaveRT miniport driver is still needed to sit between Windows audio engine (part of MS Audio stack) from one site and QEMU virtio-sound HW from the other.
Relevant news: QEMU 8.2 was recently released, which finally supports virtio-sound
(a.k.a. virtio-snd
). So at least there is now a common hypervisor out there in which such a paravirtualized guest driver could be tested.
See https://www.phoronix.com/news/QEMU-8.2-Released
Of course, it would still be great if mvisor and other hypervisors would also gain support for it. Increased adoption, choice and competition is always good. :slightly_smiling_face:
I also just submitted a Feature Request to the Cloud Hypervisor project. I hope they will take it into consideration. :crossed_fingers:
Hey, this is interesting! Judging from these commits, it would appear that the VirtualBox developers are currently working on virtio-sound as well, apparently because they are adding support for ARM VMs. :slightly_smiling_face:
In response to my feature request for virtio-snd support, one of the Cloud Hypervisor developers asked the following question:
Could you share a use case where sound is required for a cloud computing workload?
I mentioned a few I could think of (notably cloud gaming), but perhaps others here have other good examples, which could help convince them to add support for virtio-snd? If so, please share them in the issue thread.
Thanks! :slightly_smiling_face:
hi, blind screen reader user here, having a virtio sound device instead of a emulated device would really reduce latency. specially important when navigateing with screen readers. also having such a device would mean less CPU usage due to not having to emulate a device? please correct me if i'm wrong about this. that's my usecase for having such a device. less latency would mean less lag when listening for speech output. I hope you take this in to considderation.
i'm just a enduser no programmer. thank you for the virt-io drivers! Majid
Hi all, Honestly, I do not see any strong reason why the latency of virtio-snd will be better than one of HDA. I understand the motivation for virtio-snd from the aspect of PCI-less systems where HDA is not a solution. Even in this case the audio can be implemented with emulated usb-audio which will be able work with standalone USB aidio driver. Probably the use case of virtio-snd is something like automotive systems where the almost all the hardware devices are virtio-based. Windows is not so friendly to audio devices that use proprietary buses.
@ybendito But since the virtio-snd device is designed from the ground up to be paravirtualized, wouldn't it at the very least reduce emulation overhead? Preventing the need for port-trapping, unnecessary VMExits, the complexity of having to emulate specific hardware devices, etc?
And honestly, I wouldn't consider VirtIO a "proprietary" bus. It's the industry standard for paravirtualized device drivers, blessed by OASIS.
Hello @YanVugenfirer ,may I ask if it's related to the feature about the work supporting virtio-sound on Windows, Thank you in advance.
Hi @anyboo, yes this is am issue about virtio-sound support
@YanVugenfirer nice to meet you! May I inquire about the progress of the work? Do you have any suggestions for supporting virtio-snd on Windows? In my experiments, I have noticed that USB audio exhibits higher latency with increased CPU usage on ARM notebooks(eg. HuaWei I420 with Kirin 9006C). Thanks for your attention. I’m looking forward to your reply.
@anyboo, unfortunately, we don't have current plans to start working on virtio-snd. However, having interest from the community might change the plans in the future. I am also OK with supporting someone who want to take on himself the development.
The VIRTIO specification defines a sound device, do you have any plans to develop this driver and simulate this device on QEMU?