Audio (via Pulseaudio) inside Container

Tutorials
21

My Devuan container’s apt command couldn’t find any dbus-user-session, just installed the pulseaudio-utils package.

At the container, there was no alsa, nor pipewire working, just pulseaudio.

Followed the troubleshooting webpage that you suggested, in particular this:

Audio
To test audio, run pactl info command couple of times, fast. If it shows Connection failure: Access denied at least once, then try copying pulseaudio cookie from host ~/.config/pulse/cookie to the container:

incus file push -p --mode=600 --gid=1000 --uid=1000 ~/.config/pulse/cookie <instance_name>/home/ubuntu/.config/pulse/

After copying the cookie, sound started working.
This cookie file is different than the one that was at the <instance_name>/home/MYUSER/.confg/pulse/.
This issue is solved.

Still, if I want to have sound coming from other containers, can I have the same cookie for all of them?
Another question: the video rendering inside the container is sub-optimal. Can containers (one or more) use video rendering by hardware without excluding the host system to do the same?

Thank you very much for your help on this @qkiel and @simos.

22

The PulseAudio Cookie is some secret information. Whichever process tries to connect to the PulseAudio socket, they have to authenticate with the PulseAudio server by providing the secret information of the cookie.

A process in an Incus container is not much different from a process on the host, like a browser or a music player. Those processes on the host have access to the ~/.config/pulse/cookie PulseAudio cookie, and can then authenticate to the PulseAudio server through the PulseAudio socket at /run/user/1000/pulse/native.

By giving access to 1) the PulseAudio socket to the container and 2) the PulseAudio cookie, any process in an Incus container can play audio. Therefore, you can replicate this process and give audio to any Incus container through the same way. Multiple containers is fine.

@qkiel has a guide on how to setup hardware accelerated graphics in a container. Most likely your setup gives software emulation to the apps in the container. Go through the guide.

Here, as well, we are using special tricks to make processes in selected containers to have access to the graphics and audio subsystems. When we do it properly, the host does not differentiate between processes on the host, and processes in containers of the host.

1 Like
23

Hardware video rendering can be enabled inside the container without excluding the host or any other container. First, you need to check what uid the video group has on the host:

getent group video

In my case it’s 44. So I have to add GPU to the container using this command:

incus config device add <container_name> gpu gpu gid=44

Now inside container your user should belong to the video group (I also add my user to render group)

sudo usermod -a -G video,render $LOGNAME

Restart the container, and check the /dev/dri/ folder:

ls -l /dev/dri/

My output shows that card1 and renderD128 belong to root video:

crw-rw---- 1 root video 226,   1 mar  6 10:03 card1
crw-rw---- 1 root video 226, 128 mar  6 10:03 renderD128

Now you should have hardware video decoding without excluding the host or any other container.

2 Likes
24

It worked fine, @qkiel, thank you very much!