Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

virtio-sound #929

Open
Mingwang-Li opened this issue Jun 20, 2023 · 18 comments
Open

virtio-sound #929

Mingwang-Li opened this issue Jun 20, 2023 · 18 comments
Assignees

Comments

@Mingwang-Li
Copy link

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

@YanVugenfirer
Copy link
Collaborator

YanVugenfirer commented Jun 20, 2023

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
Copy link

epilys commented Aug 24, 2023

@YanVugenfirer hello! FYI I am in the process of merging a virtio-snd device in upstream QEMU:

https://lore.kernel.org/qemu-devel/[email protected]/

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
Copy link
Collaborator

@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
Copy link

epilys commented Aug 25, 2023

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

@78
Copy link

78 commented Sep 5, 2023

@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 (tenclass/mvisor#2).

@volkertb
Copy link

volkertb commented Sep 8, 2023

  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
Copy link
Collaborator

vrozenfe commented Sep 9, 2023

@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
Copy link

volkertb commented Dec 31, 2023

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

@volkertb
Copy link

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

@volkertb
Copy link

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

@volkertb
Copy link

volkertb commented Jan 2, 2024

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! 🙂

@mhussaincov94
Copy link

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
Copy link
Collaborator

ybendito commented Jan 14, 2024

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
Copy link

volkertb commented Jan 20, 2024

@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
Copy link

anyboo commented Aug 15, 2024

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
Copy link
Collaborator

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

@anyboo
Copy link

anyboo commented Aug 16, 2024

@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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants