[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.


More information about the pulseaudio-discuss mailing list