Understanding proxy devices - pipewire in container

1

Hello, newbie to incus…

On my host I have pipewire, pipewire-pulse & wireplumber running. I have sound…

I have installed the same packages on the container…no sound from the container.

I have been trying to follow a guide to setup pipewire for an incus instance.

I have also tried to familiarize myself with proxy devices by going through the lxd proxy devices video.

My understanding is that the device options:

  • listen → the address to listen for traffic
  • connect → the address to send traffic
  • bind=instance → listen on the instance and send to host

I execute the configuration from the guide

 incus config device add arch-container \                                                                                                             12:23:37
        PipewireSocket1 \
        bind=instance \
        connect=unix:/run/user/1000/pipewire-0 \
        uid=1000 \
        gid=1000 \
        listen=unix:/tmp/pipewire-0 \
        mode=0777 \
        security.gid=1000 \
        security.uid=1000 \
        type=proxy

Am I correct in thinking that, the above command is adding a proxy device that should listen on /tmp/pipewire-0 in the instance & forward traffic to /run/user/1000/pipewire-0 on the host?

What actually happens is that on the host machine I can see /tmp/pipewire-0 (and /tmp/pipewire-0-manager). They are not on the instance.

So when I export PIPEWIRE_REMOTE=/tmp/pipewire-0-manager on the instance and then try to test pw-play I get an error: error: pw_context_connect() failed: Host is down. I am guessing that’s because the socket is not there…

Is the configuration correct?

One final stupid question, if I am going to be sending the traffic to the host then why do I need to install pipewire, etc on the instance?

I have a feeling I am missing a few fundamental concepts…

Thanks in advance

2

See Incus / LXD profile for GUI apps: Wayland, X11 and Pulseaudio for fresh instructions.

By using proxy devices in Incus, you make available the host’s Unix sockets for Pipewire to processes in the container. You are loosening up the isolation of the container by giving out access to those Unix sockets. The Pipewire service on the host does not realize that a process in some container has become yet another first-class consumer of audio.

In the container you only need the client part of the audio software to run, because you are placing carefully the live Unix socket that directs to the host. A process in the container will use the client libraries of PipeWire to access the Pipewire Unix socket, and send/receive audio.

1 Like
3

Thank you. I was able to follow the guide and get audio working in my container. It also helped me understand how proxy-devices & unix-sockets are being used.