support pulseaudio via pipewire

[Andrwe]

Hi,

I just face the same issue as #238 after switching to pipewire via http://ppa.launchpad.net/pipewire-debian/pipewire-upstream/ubuntu.
I also found #380 were you stated that you do not see a reason for implementing pipewire support.

When running pipewire the pactl command cannot create its own socket.
A solution I found was to mount the existing pulseaudio socket created by pipewire into the container for /x11docker/pulseaudio.socket like this:
-v "$(LC_ALL=C pactl info | grep 'Server String' | cut -d' ' -f3):/x11docker/pulseaudio.socket"

Maybe it could be implemented as fallback when socket creation using pactl fails.

I tried adding the required code myself but haven't found the intended way to add a volume to the Backendcommand.
If you can give me a hint on that I'll create a pull request.

Regards,
Andrwe

[mviereck]

When running pipewire the pactl command cannot create its own socket.

This is odd. Why/how could pipewire disallow this?
I had issues with pactl e.g. if running as root.

A solution I found was to mount the existing pulseaudio socket

I would not like to share the existing socket. This might cause security issues.

Could you please try to run with --pulseaudio=tcp? Maybe that works.

[Andrwe]

When I'm running in tcp-mode pulseaudio clients exit with timeout:

$ time pactl info
Connection failure: Connection refused

real    0m5.021s
user    0m0.005s
sys     0m0.012s

[Andrwe]

As far as I understand the Pipewire documentation about modules the module module-native-protocol-unix does not exist which is causing the error Failure: No such entity.
An alternative module seems to be libpipewire-module-protocol-native but I haven't got it working yet to generate a new socket to access audio.

The TCP module module-native-protocol-tcp exists but the created socket is not accessible within the container:

(check using x11docker/check)

[mviereck]

Thank you for the details!

I was not aware that pipewire directly supports pulseaudio commands. that should make things easier.
I have removed pulseaudio and installed pipewire to reproduce your setup.
However, it does bot work well yet.
I have to manually start pipewire-pulse. Than pactl info works and shows pipewire in the Server Name.
But pavucontrol finds no devices.

Regarding the tcp issue:
Regardless which module I try to load, I get an error. Example:

$ pactl load-module module-native-protocol-tcp listen=127.0.0.1
Failure: No such entity

What do you get with this command?

[Andrwe]

Thanks for testing this setup.

Running the command on my host system works:

$ pactl load-module module-native-protocol-tcp listen=127.0.0.1
536870912

To run pavucontrol IIRC you have to start the following services as user (at least they are running on my system):

systemctl start --user pipewire-session-manager.service pipewire-media-session.service pipewire-pulse.service

When I stop pipewire-media-session I get the same error as you do.

[mviereck]

Ok, after some attempts I finally got pipewire to work. Your hint with pipewire-media-session was useful. The version for debian bullseye was unusable, so I've installed some pipewire packages from debian testing, and after some systemd service setup I got it to work. For the host pipewire works like pulseaudio now.

Now I can reproduce your issue.
Because on host everything else works as it should, I assume there is a bug in the tcp module of pipewire.
Not sure yet what to do, will think over it.

The command x11docker uses:

pactl load-module module-native-protocol-tcp port=55339 auth-ip-acl=172.20.0.4

(port and IP can differ)
The command seems to succeed and I get a module number. But access fails.

Note: For --pulseaudio=tcp x11docker also needs --network to allow network access.

I also tried

pactl load-module module-native-protocol-tcp listen=172.20.0.4

but failed, too.

[mviereck]

Today the load-module command fails again. Don't know why.
I won't hunt pipewire bugs further. After all, it is in an early development state. We can hope that things will improve.

As a workaround, I've introduced option --pulseaudio=host that allows to share the host pulseaudio socket.
This is basically the proposal you have made in your first post.
It is not implemented as a fallback because I think this should not be used automatically. But it can be specified manually.

[Andrwe]

The host mode works for me too.
After further debugging an researching I found https://bbs.archlinux.org/viewtopic.php?id=272200 which points to a pipewire-pulse bug https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1863.
According to that the TCP access control implementation of pipewire-pulse is broken and does not allow any connections resulting in the timeout we are seeing.
This can only be fixed by replacing pipewire-pulse with the successor project wireplumber.

Unfortunately I cannot test that ATM but the host mode solves this issue for now.

Thanks for debugging and implementing the workaround.

[mviereck]

After further debugging an researching I found https://bbs.archlinux.org/viewtopic.php?id=272200 which points to a pipewire-pulse bug https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1863.

Good to know, thanks for investigation!
So at some point in future when the fix is available in general it should just work for x11docker. For now x11docker prints a message if it detects pipewire and gives a hint to use --pulseaudio=host.