[pulseaudio-discuss] container support
temptempor at gmail.com
Mon Dec 14 19:43:03 UTC 2020
One important is that you should be in the group that has ReadWrite
access to the audio devices.
On Arch, this would be the "audio" group, which my user is part of.
Check the group ownership of the sound devices and make sure the user
that wants to execute the PA server is part of those.
Another thing there can only be one daemon owning the audio devices: if
you try to start a PA server while another is already exclusively
accessing them, your new PA daemon will fail to grab them.
So there may indeed be further Systemd ever elusive restrictions in
place but make sure: Your user is in the right group, no other PA server
is running before executing the userspace service.
On 14/12/2020 15:57, Jan Van den Audenaerde wrote:
> Thanks for sharing.
> I tried this but when starting pulseaudio daemon as a systemd user
> service it doesn't recognize the audio card.
> I have reported the details of this issue under following forum topic:
> * https://forums.centos.org/viewtopic.php?f=54&t=76657
> Note that it recognizes my audio card when launched from the command
> line for the same user ,
> so "systemctl --user" somehow restricts access to the device.
> Op zo 13 dec. 2020 om 19:27 schreef GMAIL <temptempor at gmail.com
> <mailto:temptempor at gmail.com>>:
> I have this working:
> *# /usr/lib/systemd/user/pulseaudio.socket
> Description=Sound System
> *# /usr/lib/systemd/user/pulseaudio.service
> Description=Sound Service
> # We require pulseaudio.socket to be active before starting the
> daemon, because
> # while it is possible to use the service without the socket, it
> is not clear
> # why it would be desirable.
> # A user installing pulseaudio and doing `systemctl --user start
> # will not get the socket started, which might be confusing and
> problematic if
> # the server is to be restarted later on, as the client autospawn
> # might kick in. Also, a start of the socket unit will fail,
> adding to the
> # confusion.
> # After=pulseaudio.socket is not needed, as it is already implicit
> in the
> # socket-service relationship, see systemd.socket(5).
> ExecStart=/usr/bin/pulseaudio --daemonize=no --log-target=journal
> # Note that notify will only work if --daemonize=no
> On 13/12/2020 17:52, Jan Van den Audenaerde wrote:
>> Thanks for the response.
>> But how do I get the pulseaudio daemon running in userspace that
>> is listening to unix socket /run/user/1000/pulse/native ?
>> I don't want to start this daemon manually but as a systemd service.
>> Op zo 13 dec. 2020 om 14:40 schreef GMAIL <temptempor at gmail.com
>> <mailto:temptempor at gmail.com>>:
>> This can be achieved fairly "simply" (as long as you know
>> what to look for).
>> You need to pass the pulse socket into the container and tell
>> pulse clients inside the container its precise path.
>> So on Docker CLI, for a typical Pulse daemon running in
>> userspace, it would be something like:
>> *|-v /run/user/1000/pulse:/run/user/1000/pulse |*
>> Inside the container, once you've installed Pulseaudio, you
>> need to modify its client configuration:
>> *default-server = /run/user/1000/pulse/native*
>> With this your Pulseaudio applications should be able to play
>> sounds through the host PulseAudio server (of course, you'd
>> need to adapt the runtime paths to your environment).
>> Bear in mind, there seems to be some inconsistencies in the
>> way various Pulse utilities interface with the daemon. In
>> this setup for example, "pacmd" won't work, whilst "pactl"
>> works fine once the client configuration is fixed.
>> You could test this in a manual way first and then automate
>> things a bit with a Dockerfile and what not.
>> Best regards.
>> On 12/12/2020 16:19, Jan Van den Audenaerde wrote:
>>> I have spend several days without success figuring out how I
>>> can use pulseaudio in a container setup on an embedded device.
>>> /I am running CentOs 8 on a headless device (intel-nuc)
>>> which is also running docker.
>>> I would like to run pulseaudio server on the host (CentOs 8)
>>> and my docker containers should be able to use pulseaudio
>>> client to communicate with the pulseaudio server via
>>> pulseaudio unix socket.
>>> Moreover it should be possible that different docker
>>> containers can access the microphone and speaker at the same
>>> The main problem I am facing I have reported in following
>>> forum post:
>>> * https://forums.centos.org/viewtopic.php?f=54&t=76643
>>> Any help would be much appreciated.
>>> I also think that pulseaudio has the good requirements for
>>> use in a container setup if I only can make it work.
>>> pulseaudio-discuss mailing list
>>> pulseaudio-discuss at lists.freedesktop.org <mailto:pulseaudio-discuss at lists.freedesktop.org>
>>> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss <https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss>
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at lists.freedesktop.org
>> <mailto:pulseaudio-discuss at lists.freedesktop.org>
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at lists.freedesktop.org <mailto:pulseaudio-discuss at lists.freedesktop.org>
>> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss <https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss