VirtIO Sound Driver Coming For Linux 5.13

[oiaohm]

Virtio drivers such as block, net, input have already been found successful, and virtio-snd could - perhaps- also be. Remains to be seen. It is good that there is support coming in Linux 5.13 for a virtio-snd FE driver, but so far there seems to be little available on the back-end side. And for testing purposes, a QEMU backend would be very nice to have.

I see this as a long term fix. Remember items like qemu have to emulate sound hardware. So qemu is emulating HDA audio device now HDA audio device has some quirk the windows driver gets updated now its incompadible with qemu. This has in fact happened.

virtio-snd device for a virtual machine makes sense.
1 you don't have to emulate the behaviours of quirky hardware.
2 the drivers are truly for virtual machine usage.
3 lower overhead because you don't have to emulate real hardware behaviours like slow inits and so on.

Reasons for virtio block, net, input being successful is the same problem. For virtual machines if possible you are better off with drivers for virtual machines.

Yes vendor particular passthough support on hardware does have its downsides as well as it performance advantages. Quirky hardware and the quirky drivers to support it have always been a problem then how to isolate your virtual machine images from these quirks has been a problem starting with the first virtual machine setups. virtio stuff is being very good at drawing a line at the hypervisor/virtual machine software so quirky hardware and drivers is the hosts problem not the virtual machine image/guest problem.

[Jabberwocky]

Out of curiosity, can you link your DAC, please?

Sorry for the delay, I was gone for a few days. I've got a Sennheiser GSX 1200 Pro and previously Asus Xonar U7 which I used in the same way.

[toninikkanen]

I guess people are mostly concerned with desktop usage in the comments above.

I am in the embedded automotive world where virtualization is commonly used. And we have plenty of use cases where a lower level interface such as ALSA is strongly preferable vs. Pulse Audio. So far, I guess most vendors have been using native pass-thru drivers for audio, but there is a trend to avoid introducing too many HW vendor-specific dependencies into software stacks because hardware comes and goes, and eventually you have to support multiple generations of hw, all with different sets of drivers.. And also multiple variants in the same generation...

Virtio drivers such as block, net, input have already been found successful, and virtio-snd could - perhaps- also be. Remains to be seen. It is good that there is support coming in Linux 5.13 for a virtio-snd FE driver, but so far there seems to be little available on the back-end side. And for testing purposes, a QEMU backend would be very nice to have.

[oiaohm]

I didn't say it was so great, I'm saying it's a sensible solution for VMs due to the nature of it's structure and its wide adoption.
Pipewire is created by RH so obviously they're going to push for it. I'm not suggesting there's anything wrong with PW either, though I don't know if it's a drop-in replacement for PA. At least not yet.

Something to remember Redhat backed the move from esound and other sound servers to pulseaudio back in history as well.

For some users Pipewire is already a drop in replacement for Pulseaudio without any trouble. Some of this comes down to distribution and packages you are using. Some packages in some distributions have a hard solid dependency on pulseaudio when they work 100 percent fine with pipewire pulseaudio emulation.

For some uses changing to pipewire allows removing jackaudio and pulseaudio so no longer having to play the sound server shuffle so making their life way better.

https://github.com/wwmm/pulseeffects We are also starting to see items like pulseeffects that use to support pulseaudio that going forwards will only support pipewire with the newest features.

Yes pipewire provided emulated pulseaudio and jackaudio and alsa audio backend but it also has it own native pipewire backend in different things like gstreamer and pulseeffects....

Thing to remember pipewire can emulate pulseaudio but pulseaudio cannot emulate pipewire. Remember pipewire covers video as well as audio pipewire is more of a all round tool than pulseaudio and jackaudio are.

Really it would be interesting to see a DJ tool built to take advantage of what pipewire is because in theory this could be the video dj and the audio dj on a single system with proper shared sync.

[schmidtbag]

If pulseaudio is so great, how come RedHat devs are replacing it? It's because they know it has issues with latency and CPU usage amongst other things. I don't like everything RH does (I'm no 144Hz fanboy), but pipewire looks very promising and has gotten good reviews from early adopters.

I didn't say it was so great, I'm saying it's a sensible solution for VMs due to the nature of it's structure and its wide adoption.
Pipewire is created by RH so obviously they're going to push for it. I'm not suggesting there's anything wrong with PW either, though I don't know if it's a drop-in replacement for PA. At least not yet.

If I had my way, I wouldn't use PA on my non-VMs, but too many things depend on it and it makes 5.1 surround a breeze to set up compared to bare ALSA.

[microcode]

Wonder how this really compares to just using PA, or alsa loopback with virtio-vsock or whatever. I don't mind either way, one of these days it would be cool to have hardware or a hardware/firmware hybrid that satisfies the VirtIO interfaces at a low level (maybe even virtio-fs, and virgil or similar).

[DanL]

I appear to understand how PA works better than you. For one thing, I don't get the same issues with it as you.

If pulseaudio is so great, how come RedHat devs are replacing it? It's because they know it has issues with latency and CPU usage amongst other things. I don't like everything RH does (I'm no 144Hz fanboy), but pipewire looks very promising and has gotten good reviews from early adopters.

[schmidtbag]

Right, I assume you're talking about networked pulseaudio then. That is shittier than everything else.
My first response addressed that. Read again, you don't seem to be very good at that.

Go away, troll. You clearly don't have a clue what you are talking about.

wtf? PA is always networked... When you run it from the same machine, it just goes to localhost.
Your first response implied only microphones didn't work over a network. My reading comprehension is fine, your writing skills are what need work.
I appear to understand how PA works better than you. For one thing, I don't get the same issues with it as you.

[Fidelix]

Clearly, you didn't read my post if that's what you think my suggestion was.

And if you spend the same amount of time searching for fixes, you'd find one.

No... my point is it's likely not 100ms and you're either exaggerating or your configuration is bad.

Uh-huh. Then how about you stop arguing with me?

Hypocrite. You don't even realize what PA actually is. If you understood my point, you wouldn't be making such a foolish statement.
PA has both server and client functionalities. You run the server on the OS with the driver support and you run the client on the guest. That way, the guest doesn't need drivers and you don't need to emulate anything. It's not a hard concept to grasp, but you're so busy wiping the foam from your mouth.

Right, I assume you're talking about networked pulseaudio then. That is shittier than everything else.
My first response addressed that. Read again, you don't seem to be very good at that.

Go away, troll. You clearly don't have a clue what you are talking about.

[schmidtbag]

If you use qemu with pulseaudio, you're using an emulated device (intel hda, usually).

Clearly, you didn't read my post if that's what you think my suggestion was.

Seriously, it would have taken you 10 seconds to google search "pulseaudio hdmi delay" or "latency" and you'd get hundreds of posts.
If you think that is just anecdote, and you were discussing in good faith, that's how easy it would be to verify what I am saying.

And if you spend the same amount of time searching for fixes, you'd find one.

You're being silly, and patronising. 100ms is very noticeable and annoying for any normal human being.

No... my point is it's likely not 100ms and you're either exaggerating or your configuration is bad.

If virtio audio wouldn't be useful for you, that's fine.

Uh-huh. Then how about you stop arguing with me?

You're just plain wrong.
Learn to recognise when you're wrong and move on.

Hypocrite. You don't even realize what PA actually is. If you understood my point, you wouldn't be making such a foolish statement.
PA has both server and client functionalities. You run the server on the OS with the driver support and you run the client on the guest. That way, the guest doesn't need drivers and you don't need to emulate anything. It's not a hard concept to grasp, but you're so busy wiping the foam from your mouth.