[pulseaudio-discuss] Problem: non-interactive pulseaudio ( headless )

Brian Bulkowski brian at bulkowski.org
Mon Sep 2 06:15:05 UTC 2019


Hey Arun,

Thanks for responding.

> I usually point folks to the sync-playback.c test that we have a starting point, but this is certainly less than ideal.

"less than ideal" is quite the politeness. Let's see....

1) it doesn't cover files, nor does it cover files of different types ( 
mp3 vs wav )

Files are very good because they always work locally, which is critical 
in art installations where you are being paid to deliver an experience, 
regardless of whether there is connectivity. Unlike streams. Streams are 
useless.

2) it doesn't cover changing sounds in response to an "interrupt", that 
is, pressing a button on an art installation.

3) it doesn't cover multiple "layers", that is, different sound 
experiences being added or subtracted by buttons.

Pulse audio is great all all of this, just that the example code is, to 
put it your polite fashion, less than ideal, or where I come from, an 
embarrassment.

The code I've written allows external REST requests, and allows the 
player to make REST requests to find current state. REST being the 
current lingua franca of the internet. And allows both volume changes 
and source file changes. Hopefully committed literally tomorrow, putting 
it through some extra tests. Will post with a permissive license.

>
>> 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.
I don't know why I struggled with cookie files for 3 days. The fact that 
the created cookie file was only rw on the pulse user, and not r on the 
group, slowed me down --- why shouldn't pulse group members be allowed 
to use pulse audio? And what did I do wrong so that the environment 
variable didn't work? I won't immediately assume a bug in pulse, but.... 
multiple tries..... no examples.....


-brian



More information about the pulseaudio-discuss mailing list