Incus 6.8 Audio problems

Madeiba · December 24, 2024, 5:00pm

Hi all,

After much testing, I think I need help with the audio in incus.
My environment:

Ubuntu 22.04.5 host running on a laptop.
Incus 6.8 stable installed from the zabbly repository.
Several guests, mostly Debian 12 with xfce.

My tests for now:

I start a vm with the standard options:

[rc:0 2024/12/24 14:50:30 root@IM2352 ~] # incus launch images:debian/12 deb1 --vm
[rc:0 2024/12/24 14:52:10 root@IM2352 ~] # incus exec deb1 -- apt install xfce4 xfce4-goodies spice-vdagent vlc pciutils
[rc:0 2024/12/24 14:57:42 root@IM2352 ~] # incus exec deb1 -- reboot
[rc:0 2024/12/24 14:57:49 root@IM2352 ~] # incus console deb1 -t vga

In this setup I have no sound in the guest. If I open the xfce4-mixer, there is only a dummy output.
A lspci show me no sound card. The Ubuntu host sound is working correctly.

I specify a sound card in my deb1 vm:

[rc:0 2024/12/24 15:04:09 root@IM2352 ~] # incus stop deb1
[rc:1 2024/12/24 15:06:27 root@IM2352 ~] # incus config set deb1 raw.qemu -- "-device intel-hda -device hda-duplex -audio spice"
[rc:0 2024/12/24 15:06:39 root@IM2352 ~] # incus start deb1
[rc:0 2024/12/24 15:06:43 root@IM2352 ~] # incus console -t vga deb1

In this setup I have guest audio working correctly. But my Ubuntu host lost audio because the device is in use:

pulseaudio[27149]: Error opening PCM device front:0: Dispositivo o recurso ocupado

In contrast, If I open the audio device on the host before booting the guest, I have audio in the host but not in the guest.

Someone recommends me to use PulseAudio driver in qemu, but the qemu version distributed with incus lacks support of PulseAudio.
At this point I think than using PulseAudio network capabilities would be my solution. I’ve configured host PulseAudio to listen on the network. I’ve configured guest PulseAudio to send audio to host. I’ve removed raw.qemu directives from deb1 vm. But, unfortunatelly, the guest keeps opening the sound device exclusively, so the host lost audio access. If I open the audio device from the guest, there is no sound at all (because the host cannot open the audio device, but receives the guest audio stream from network). If I open the audio device from the host first, everything works as expected. The host audio works correctly, and the guest send the audio stream to the host via network, so the host can reproduce it…)
I’ve tryed console access with remote-viewer and spicy. Both of them works the same related to audio devices.

so, this is my question. Is there any easy solution to this issue. Simply, I need to access to audio devices from host and guests…

Regards,

simos · December 25, 2024, 8:43pm

Welcome!

How do you setup PulseAudio over the network? There is a summary of instructions, for example, at How to set up PulseAudio over Network · GitHub

It is strange if network access would block access to the PulseAudio sound server.

Madeiba · December 26, 2024, 12:00pm

HI,

My pulseaudio network setup is very easy:

On ubuntu host, I’ve configured PulseAudio to listen on network, and I’ve opened the firewall port:

# echo "load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.8.0/23" > /etc/pulse/default.pa.d/network.pa
# firewall-cmd --zone=internal --add-service=pulseaudio --permanent
# firewall-cmd --reload

On incus guest, I’ve configured PulseAudio to send audio to host ip address:

# echo "default-server =  tcp:192.168.8.1:4713" /etc/pulse/client.conf.d/server.conf

Also I’ve installed the host PulseAudio cookie in the guest.
I’ve restarted host and guests to apply all changes.

I have no doubt about the PulseAudio network configuration. Even when I hear no sound playing some audio on guest, I see a lot of traffic on port 4713/tcp, and I can verify audio volume in host and guest are synchronized.

My problem (I think) is related to spice clients (remote-viewer and spicy).
A new sequence of tests:

Clean system. Ubuntu host restared. Guest started.
I can verify with lsof than the only /dev/snd/ devices opened, have been opened by PulseAudio:

[rc:0 2024/12/26 09:33:09 root@IM2352 ~] # lsof 2>/dev/null | grep "/snd"
pulseaudi 2078                           nacho   16u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078                           nacho   23u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078                           nacho   28u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078 2756 alsa-sink            nacho   16u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078 2756 alsa-sink            nacho   23u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078 2756 alsa-sink            nacho   28u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078 2759 alsa-sour            nacho   16u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078 2759 alsa-sour            nacho   23u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078 2759 alsa-sour            nacho   28u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078 2918 snapd-gli            nacho   16u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078 2918 snapd-gli            nacho   23u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi 2078 2918 snapd-gli            nacho   28u      CHR             116,10         0t0        996 /dev/snd/controlC0
[rc:0 2024/12/26 09:33:24 root@IM2352 ~] #

I can play audio on host without problem.
I can connect to guest through ssh an play sound with aplay.
I can connect to guest through vnc. I can play sound with vlc.
At this point, If I open incus graphical console (remote-viewer), and login to lightdm(without playing anything at all, I’ve only logged in), I can see a lot of soud devices opened by remote-viewer:

[rc:0 2024/12/26 12:29:56 root@IM2352 ~] # lsof 2>/dev/null | grep "/snd"
pulseaudi  2078                            nacho   16u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078                            nacho   23u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078                            nacho   28u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078  2756 alsa-sink            nacho   16u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078  2756 alsa-sink            nacho   23u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078  2756 alsa-sink            nacho   28u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078  2759 alsa-sour            nacho   16u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078  2759 alsa-sour            nacho   23u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078  2759 alsa-sour            nacho   28u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078  2918 snapd-gli            nacho   16u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078  2918 snapd-gli            nacho   23u      CHR             116,10         0t0        996 /dev/snd/controlC0
pulseaudi  2078  2918 snapd-gli            nacho   28u      CHR             116,10         0t0        996 /dev/snd/controlC0
remote-vi 25258                             root  mem       CHR              116,3                    983 /dev/snd/pcmC0D0c
remote-vi 25258                             root  mem       CHR              116,2                    982 /dev/snd/pcmC0D0p
remote-vi 25258                             root   22r      CHR             116,33         0t0        595 /dev/snd/timer
remote-vi 25258                             root   23u      CHR              116,2         0t0        982 /dev/snd/pcmC0D0p
remote-vi 25258                             root   24u      CHR             116,10         0t0        996 /dev/snd/controlC0
remote-vi 25258                             root   27r      CHR             116,33         0t0        595 /dev/snd/timer
remote-vi 25258                             root   28u      CHR              116,3         0t0        983 /dev/snd/pcmC0D0c
remote-vi 25258                             root   31u      CHR             116,10         0t0        996 /dev/snd/controlC0
remote-vi 25258 25259 gmain                 root  mem       CHR              116,3                    983 /dev/snd/pcmC0D0c
remote-vi 25258 25259 gmain                 root  mem       CHR              116,2                    982 /dev/snd/pcmC0D0p
remote-vi 25258 25259 gmain                 root   22r      CHR             116,33         0t0        595 /dev/snd/timer

I lost audio output on that point. Every access to audio device on host ends with pulseaudio error: pulseaudio[2078]: Error opening PCM device front:0: Dispositivo o recurso ocupado

If I close remote-viewer, all audio devices are released, and I get audio output back on the host.

Why does remote-viewer open all those audio devices? Can I avoid this behavior of remote-viewer?

My vm has no reference to audio devices:

[rc:1 2024/12/26 12:48:27 root@IM2352 ~] # incus config show deb1
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian bookworm amd64 (20241224_05:24)
  image.os: Debian
  image.release: bookworm
  image.serial: "20241224_05:24"
  image.type: disk-kvm.img
  image.variant: default
  volatile.base_image: db2c9ea062aff29ff634b8b710af726a61abef05f9ad42e0b7290625f4e32e86
  volatile.cloud-init.instance-id: dfe5987b-f01b-4aac-8784-80485323fbbd
  volatile.eth0.host_name: tap7da3d12e
  volatile.eth0.hwaddr: 00:16:3e:0b:7d:05
  volatile.last_state.power: RUNNING
  volatile.uuid: b6b9acf8-95ed-4718-afa7-ba689b5c9bf2
  volatile.uuid.generation: b6b9acf8-95ed-4718-afa7-ba689b5c9bf2
  volatile.vsock_id: "856986660"
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""
[rc:0 2024/12/26 12:48:30 root@IM2352 ~] #

I also tryed setting audiodev=none:

[rc:0 2024/12/26 12:53:04 root@IM2352 ~] # incus config set deb1 raw.qemu -- "-audiodev none,id=none"

but remote-viewer’s behavior remains the same…

Regards,

Madeiba · December 26, 2024, 1:57pm

Ok,

I was launching remote-viewer as root all this time.
If I access to incus graphical console with my personal user, the audio devices are not locked up, and I can play sounds on host/guest as expected…

Regards