You are not logged in.

#1 2021-11-19 13:41:15

burny02
Member
Registered: 2021-07-01
Posts: 23

Pipewire - KVM, QEMU, Libvirt, VM

Hi;

Does anyone know if there is a method of sending through Pipewire audio to a VM, much like my current pulseaudio version below?

I find that the pulseaudio one does work quite nicely, but only if the audio quality on windows is dropped

    <sound model="ich9">
      <audio id="1"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/>
    </sound>
    <audio id="1" type="pulseaudio" serverName="/run/user/1001/pulse/native">
      <input mixingEngine="no"/>
      <output mixingEngine="no"/>
    </audio>

Offline

#2 2021-11-19 14:36:01

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 15,077

Re: Pipewire - KVM, QEMU, Libvirt, VM

No, you could try ALSA or add some latency to the pulseaudio in/out invocations. Maybe also elaborate on "dropping the audio quality" and what that means exactly in your case. It could also be up the virtualized sound card in which case you might want to try a different sound card driver.

Last edited by V1del (2021-11-19 14:37:04)

Offline

#3 2021-11-19 21:39:15

burny02
Member
Registered: 2021-07-01
Posts: 23

Re: Pipewire - KVM, QEMU, Libvirt, VM

Tried ALSA, and I get nothing.
Also tried with latency...And I get echo.

It seems like mixing engine & latency are exclusive as one is removed if saved with both.

Arch Wiki has a great article on sound for anyone else reading: here

For sound quality, I mean within windows.

The best I seem to get is with the settings above, and then lowering the sound quality in windows

default-sound-format.png

I did just wonder if there was a Pipewire method, can't seem to find anything though

Last edited by burny02 (2021-11-19 21:40:34)

Offline

#4 2021-11-20 14:59:21

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 15,077

Re: Pipewire - KVM, QEMU, Libvirt, VM

How well a certain sample rate behaves is almost certainly unrelated to pulseaudio and more likely to be up to the emulated card that then has to do explicit resampling if you pick a rate that isn't actually supported. "Lowering the sound quality" will in many, many cases not actually be perceptible to you but can lead to a lot of computational overhead if you do it just because "higher numbers must mean better"

Offline

#5 2021-11-20 18:04:12

burny02
Member
Registered: 2021-07-01
Posts: 23

Re: Pipewire - KVM, QEMU, Libvirt, VM

That's almost certainly the case.

Not sure how much actual quality is effected, probably not that I can hear. It must losing some overhead or something though; as the delay/crackling/echo all disappear

Offline

#6 2021-11-20 18:49:38

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 15,077

Re: Pipewire - KVM, QEMU, Libvirt, VM

I'm assuming you are actually selecting the native sample rate of your physical card and thus little to no unnecessary resampling has to be done. Maybe post

pactl list sinks
pactl list sink-inputs

during working and not working to check what the pipeline actually looks like.

Offline

#7 2021-11-20 21:03:00

burny02
Member
Registered: 2021-07-01
Posts: 23

Re: Pipewire - KVM, QEMU, Libvirt, VM

So I can see the sample rate of

pactl list sink-inputs

changing as I change the setting within my windows VM

I have however been testing mainly with my headset, and using

pactl list sinks

I can see that my headset has a sample rate of 16000Hz which doesn't change

This is incidentally the setting I have stuck to as it appears to work best

Offline

#8 2021-11-21 13:49:46

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 15,077

Re: Pipewire - KVM, QEMU, Libvirt, VM

Which does make sense to me, I'm assuming the "other" setting that worked relatively well was 441kHz, and the reason for that is pretty simple.

The vast majority of "normal" audio you'll come across (mp3 files, youtube videos...) is 441kHz if you select that, Windows doesn't have to do resampling, but pipewire does. In the case you've settled on Windows does the resampling, and pipewire can directly pass the received stream. All other cases require at least two resampling passes which might show itself with the symptoms you noted.

Offline

#9 2021-11-21 16:18:27

burny02
Member
Registered: 2021-07-01
Posts: 23

Re: Pipewire - KVM, QEMU, Libvirt, VM

Not sure I tried 441kHz, just assumed that lower would be better.

Just tried and it does indeed seem pretty good at 441kHz. I can keep an eye on it.

Seems to make more sense to allow Pipewire to do the resampling, I'd assume?

Offline

#10 2021-11-23 12:54:51

burny02
Member
Registered: 2021-07-01
Posts: 23

Re: Pipewire - KVM, QEMU, Libvirt, VM

I don't suppose you know if there a method that reliably will switch audio devices whilst in the VM?

I thought this was working with pulseaudio, but again today it appears to be stuck in the output that was first present on host when the VM booted.

Here's what I would like:

Boot VM
Swap Host audio output
VM recognises and switches

I haven't been able to get it to do this reliably with spice audio or pulseaudio. Alsa I get no sound at all

Offline

#11 2021-11-23 14:58:12

burny02
Member
Registered: 2021-07-01
Posts: 23

Re: Pipewire - KVM, QEMU, Libvirt, VM

I've just noticed that this is also the case on one of my other applications also.

Auto sound device is not working, and had to be explicitly told which device.

Could this be something to do with the way cinnamon swaps devices?

Offline

#12 2021-11-23 15:18:25

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 15,077

Re: Pipewire - KVM, QEMU, Libvirt, VM

Not entirely sure what you are looking at and where. Normally I'd change that in pavucontrol or so and not touch whatever the VM does but I'm not entirely familiar with how exactly qemu exposes a audio card to the VM. "Normally" I'd assume you have one logical audio card within the VM and would change physical cards outside via pavucontrol/similar tools.

Offline

#13 2021-11-23 18:06:38

burny02
Member
Registered: 2021-07-01
Posts: 23

Re: Pipewire - KVM, QEMU, Libvirt, VM

Brilliant, that has worked a real treat.

So, cinnamon's default, you basically get a single output device. Pavucontrol you are able to swap device for each application.

I guess cinnamon was swapping it only for certain applications or something.

Had to add a launcher for pavucontrol and it still does get stuck every so often but it seems far better

Offline

Board footer

Powered by FluxBB