virtio-win / kvm-guest-drivers-windows

Windows paravirtualized drivers for QEMU\KVM
https://www.linux-kvm.org/page/WindowsGuestDrivers
BSD 3-Clause "New" or "Revised" License
1.99k stars 382 forks source link

virtio-sound #929

Open Mingwang-Li opened 1 year ago

Mingwang-Li commented 1 year ago

The VIRTIO specification defines a sound device, do you have any plans to develop this driver and simulate this device on QEMU?

YanVugenfirer commented 1 year ago

Hi @Mingwang-Li ,

I would separate two topics:

  1. virtio-snd device in QEMU. And yes, there is a work to put the device implementation to QEMU
  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.
epilys commented 1 year ago

@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.

YanVugenfirer commented 1 year ago

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

epilys commented 1 year ago

Progressing steadily, as always there's lots of important work the list and objectively virtio-sound is a low priority :)

78 commented 1 year ago

@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).

volkertb commented 1 year ago
  1. 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.

vrozenfe commented 1 year ago

@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.

volkertb commented 8 months ago

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:

volkertb commented 8 months ago

I also just submitted a Feature Request to the Cloud Hypervisor project. I hope they will take it into consideration. :crossed_fingers:

volkertb commented 8 months ago

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:

volkertb commented 8 months ago

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:

mhussaincov94 commented 8 months ago

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

ybendito commented 8 months ago

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.

volkertb commented 8 months ago

@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.

anyboo commented 1 month ago

Hello @YanVugenfirer ,may I ask if it's related to the feature about the work supporting virtio-sound on Windows, Thank you in advance.

YanVugenfirer commented 1 month ago

Hi @anyboo, yes this is am issue about virtio-sound support

anyboo commented 1 month ago

@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.

YanVugenfirer commented 1 month ago

@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.