search

mviereck / x11docker

Run GUI applications and desktops in docker and podman containers. Focus on security.
MIT License
5.62k stars 378 forks source link

--xorg and --pulseaudio: no sound #250

Closed n-krueger closed 4 years ago

n-krueger commented 4 years ago

Hi, I am using x11docker to run ROS and CARLA simulator on their official target platform, ubuntu 18.04. Because I need NVIDIA GPU acceleration, I am using the --xorg parameter together with --desktop and --gpu. All of this works perfectly fine, but I am now trying to get sound to work with --pulseaudio and I am running into the following issue:

--xephyr and --pulseaudio: Sound works, both host and container applications can use pulseaudio --xorg and --pulseaudio: Sound does not work, sound playback from host applications stops when switching to the new TTY, container applications cannot play sound

Any pointers on what the problem might be would be greatly appreciated! Dockerfile used: base Dockerfile base+CARLA Dockerfile Preset used:

--xorg
--desktop
--gpu
--pulseaudio
--home
--sudouser
--
--
x11env-ros-melodic:carla

x11docker output when running this preset: https://gist.github.com/n-krueger/8b633e36adf79232c947f19ec663c14b verbose x11docker log: https://gist.github.com/n-krueger/c498513cc685b9813ba4082059f79668

mviereck commented 4 years ago

Thank you for the report!

I've tried to reproduce the issue. Overall it works well, I can get pulseaudio sound from host X as well as from a container with --xorg --pulseaudio --gpu. I've switched ttys several times. Two times the sound from host stopped until I switched back to host X. So I could partially reproduce the issue a few times. But I have no idea what might be the cause, and I can't reproduce reliably. Likely it is some sort of pulseaudio issue.

Aside from that: GPU accelerated application stop entirely if switching to another X. You can check that if you run glxgears on both X servers. They will show wrong/low framerates. Are you sound applications GPU accelerated?

Sorry that I don't have better ideas yet.

mviereck commented 4 years ago

One idea: Maybe the image misses dependency libpulse0. The base image contains libpulse0.

n-krueger commented 4 years ago

Thank you for the suggestions! I tried x11docker/check and can reliably reproduce this behavior:

Host OS is ubuntu 20.04. I found this pulseaudio bug from 2008 on the ubuntu bugtracker: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/213149. It suggests that this is the intended behavior when pulseaudio is running in a GNOME session. I will try the suggested workarounds in that thread and report my findings.

n-krueger commented 4 years ago

Fixed by adding my user to the audio group! Both host and container audio streams play and are mixed in both X servers. The user created by the ubuntu 20.04 installation is not a member of audio.

n-krueger commented 4 years ago

https://wiki.ubuntu.com/Audio/TheAudioGroup indicates that this works because of the following:

As a practical rule of thumb for Debian and Ubuntu systems, there should be no users in the audio group. [...] Otherwise, switching to another user may leave the new user without access to sound devices. Exceptions:

  • When you want a user to be able to access a sound card even if he is not logged in.

Perhaps this is related to the uid of the host user and the container user being different?

mviereck commented 4 years ago

Fixed by adding my user to the audio group!

Great! Thank your for reporting the solution. Really odd, I've read the old bug ticket ...

I wonder if x11docker should add the container user to group audio, too. Currently it does so for option --alsa only.

The user created by the ubuntu 20.04 installation is not a member of audio.

On my debian system the user is member of audio by default, so the issue did not occur here.

mviereck commented 4 years ago

As a practical rule of thumb for Debian and Ubuntu systems, there should be no users in the audio group. [...] Otherwise, switching to another user may leave the new user without access to sound devices.

I know this effect from ALSA sound. If an application directly uses ALSA, no other application is able to play sound because the device in /dev/snd is already in use. (Though, a special ALSA mixer setup is possible to solve this.)

Perhaps this is related to the uid of the host user and the container user being different?

In x11docker containers host user and container user have the same uid and gid. Additional groups like alsa or video are only set by x11docker if needed.

mviereck commented 4 years ago

Another possibility that might have fixed the issue is option --pulseaudio=tcp. By default x11docker shares a pulseaudio unix socket that is bound to the user. A TCP setup is user independent.

n-krueger commented 4 years ago

My current theory is that the host user looses access to the sound devices when the TTY is switched. When I am not in the audio group and switch to a non-X TTY (e.g. TTY3) pulseaudio playback also stops. But after I log in, it resumes. Will give --pulseaudio=tcp a try to test that theory.

n-krueger commented 4 years ago

Will give --pulseaudio=tcp a try to test that theory.

--pulseaudio=tcp has the same issue when the host user is not in the audio group.

n-krueger commented 4 years ago

Some more investigation without being in the audio group reveals that pulseaudio playback keeps working on any TTY that has an active session for the user that is running pulseaudio in loginctl. With the following sessions:

$ loginctl list-sessions
SESSION  UID USER SEAT  TTY 
      2 1000 nils seat0 tty2
      5 1000 nils seat0 tty3
     c1  125 gdm  seat0 tty1

3 sessions listed.
$ docker container ls -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
cdd7783ddef9        x11docker/check     "env /usr/local/bin/…"   25 seconds ago      Up 24 seconds                           x11docker_X122_x11docker-check_90332770717

Pulseaudio playback works on TTY2 (ubuntu desktop) and TTY3 (console TTY), but not in TTY1 (GDM login screen). x11docker/check was running in TTY12, but the session does not show up in loginctl.

mviereck commented 4 years ago

Pulseaudio playback works on TTY2 (ubuntu desktop) and TTY3 (console TTY), but not in TTY1 (GDM login screen). x11docker/check was running in TTY12, but the session does not show up in loginctl.

An interesting investigation! Unfortunately I have no idea how to open a new seat without a full login including a password.

But maybe it makes a difference if the container user is in group audio. you could achieve this with -group-add audio or --alsa.

A new seat, but only in container, is opened with option --init=systemd. (Needs systemd in the image.) But that likely would not help here.

This one should work: If you switch to a tty, log in, and run x11docker. Than the tty has a seat. That would allow host sound to keep running.

n-krueger commented 4 years ago

This one should work: If you switch to a tty, log in, and run x11docker. Than the tty has a seat. That would allow host sound to keep running.

I can confirm that this is also a working solution! Container sound continues to run when I switch back to the host, neither --group-add audio nor --alsa is required. Looks like the host user's access to sound devices is the only variable that affects the result.

To summarize, working setups for --pulseaudio --xorg:

Greatly appreciate the support with figuring this out!

mviereck commented 4 years ago

Thank you for the interesting investigation!