[pulseaudio-discuss] Problem: non-interactive pulseaudio ( headless )
Arun Raghavan
arun at arunraghavan.net
Mon Sep 2 04:26:26 UTC 2019
Hey Brian,
Sorry about the lack of response on this. Just saw this now, and I'm glad you got things running.
On Sun, 1 Sep 2019, at 5:18 AM, Brian Bulkowski wrote:
> Here's what I learned:
>
> 1. PulseAudio paired with a Rapsberry Pi is an almost unbeatable choice
> for art installations. The ability to attach many speakers over USB
> audio, the fact that there are no fans whatsoever, the fact that is can
> run any manner of high level software to control sound, that you can add
> flash drives which are as large as you like, the fact that you can
> determine which USB port is which, the fact that you can easily add
> buttons and interaction ( since it's a PI ), the ability to control
> volume at any level ( speaker, sound, etc ), the easy code to use any
> manner of sound file.... it's great.
>
> 2. The async interface is not well covered in many guides. The examples
> are misleading. As an experienced programmer with 30+ years of async c,
> I got caught by this, because the examples worked ( but don't if you
> start and stop a lot ). I will be posting my project and showing how to
> really play sounds and start and stop them.
I usually point folks to the sync-playback.c test that we have a starting point, but this is certainly less than ideal.
> 3. If you are going to run an unattended service, you need to set
> pulseaudio to be a systemd service, and you need to set up your
> application as a systemd service.
>
> In order to do this, you would typically use the 'cookie' file, which is
> a binary file of undocumented type ( possibly just the contents of the
> file ) which more than one process need access to. My attempts to get
> this working with PulseAudio 12.0 failed, with environment variables
> ignored, a service auto-creating a file with privs hard to read, but it
> turns out there's a simple workaround. The documentation unhelpfully
> says "maybe this is a good idea for something like an unattended
> headless application but you're probably not running one of those".
The documentation is catered to users across the spectrum of use-cases and expertise, but I'm happy to incorporate suggestions for better phrasing for this.
> The way out, when you get desperate of using cookie files ( and do try
> them first ), isĀ to modify the /etc/pulse/system.pa and find the
> load-module line for module-native-protool-unix . Add the
> auth-anonymous=1 as below
>
> load-module module-native-protocol-unix auth-anonymous=1
>
> This disables checks, and means that anyone who has access to the
> raspberry pi can take over the audio, even if they have a non-pulse or
> non-audio user. An installation like this should be air-gapped anyway.
>
> 4. I can't say "thanks for the excellent community" as I spent lots of
> hours on this project, but the underlying code has been sound, so thanks
> for writing and contributing it.
>
> 5. When the code is fixed, I'll post a link for others to use.
Thanks for your patience and for writing down your findings for others.
Regards,
Arun
More information about the pulseaudio-discuss
mailing list