Hello, I'm trying to discover the best way to share pulse audio between linux containers. I have found a great deal of answers to this problem online. Some of them involve sharing UNIX sockets, while others suggest connecting via localhost using port tunneling or otherwise. I want to use UNIX sockets and take advantage of POSIX's existing and excelent naming, namespacing, and security mechanisms. I guess that shouldn't be a problem, because pulse audio seems to support unix sockets. But I'm having trouble understanding their layout or finding any documentation on what data gets transfered via which mechanism and which APIs are exposed via what protocol. So far I've found that there are unix sockets in the following places: - $HOME/.config/pulse/<gobldygook>-runtime This is just a link to: - /tmp/<gobldygook>-pulse/ But how does this differ from the one in run? - /run/user/$UID/pulse/ I seem to recall that there is also system wide socket, not associated with any single user of the system. However, I do not remember its location. There is also discussion of PULSE_AUDIO_COOKIE. Is this really needed when connecting to UNIX sockets? Are these sockets stand alone or does pulse audio also communicate over dbus or x11 or something? For my usecase, the localhost option is a non-starter. It involves configuring networking in the container to allow for the tunneling of some ports which seems fiddly and like a can of worms from a security perspective. Even if I weren't useing containers, I don't like the idea of accessing services through localhost. Numbered ports with no human readable names? No namespacing between users? Security from the outside world ensured through conventions, manual checks, and hacks? Good greif! If you have other suggestions that don't involve networking, I'd be happy to hear them. I do hope, though, that if there isn't one already, we'll be able to create a page as informative as this one <xpra container page> for using pulse audio with containers. Thanks in advance, Timothy Hobbs
