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

[Brian Bulkowski]

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.

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

-b

On 8/29/2019 12:02 PM, Brian Bulkowski wrote:
> Hey,
>
> Not like people are jumping to help out.... but
>
> There seems to be a .service file floating around the internet which 
> says the service type is "notify", which doesn't work. Getting to a 
> more normal form of service file seems to get past the auth problems I 
> was having.
>
> The next step was to understand cookie files. The pulseaudio system 
> file says it can't read the cookie file in two known locations, even 
> though there are files there and an existing path. I've tried using 
> the 'pulse' user and 'pulse' group, although there are many paths to 
> test.
>
> Using the environment variable didn't seem to pick up an existing 
> cookie file. I wish there was some kind of message saying that the 
> path was ignored or something. Of course there are many possibilities 
> of misspelling or misunderstanding.
>
> What I have noticed is there is a cookie file created by the 
> pulseaudio daemon on startup. However, it's created as rw only on the 
> pulse _user_, where it would be far nicer if the file was created 'r' 
> on the pulse group as well. That would allow a pretty sensible use of 
> the group system to determine which users could access that created 
> cookie file. However, if I have a cookie file, I will figure out a way 
> to get the over to the headless user I intend.
>
> Any hints appreciated, otherwise I'll just keep posting my signposts 
> hoping it helps someone else.
>
> -brian
>
> On 8/26/2019 9:38 AM, Brian Bulkowski wrote:
>> Hi,
>>
>> I've tried a bunch of the online guides, and I find the following 
>> problem. I am running Debian Buster on a raspberry pi with pulseaudio 
>> 12.0
>>
>> Note that I don't need to run as root. I just need to auto-start, and 
>> that usually requires running a service (systemd), and I've specified 
>> not using the root user.
>>
>> When I attempt to launch my pulseaudio service, I get the following:
>>
>>  ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
>> Authentication is required to start 'pulseaudio.service'.
>> Authenticating as: root
>> Password:
>> polkit-agent-helper-1: pam_authenticate failed: Authentication failure
>> ==== AUTHENTICATION FAILED ===
>> Failed to start pulseaudio.service: Access denied
>>
>> Appreciated hints would be: how to run a PulseAudio application in a 
>> way that it auto-start and auto-restart ( it runs on the command line 
>> for a lot of hours so maybe I'm just good with auto-start ). I have 
>> written the C code directly to pulseaudio myself so if there anything 
>> in terms of PulseAudio connect options that's great.
>>
>> * I am OK running as my user ( the default user on the raspberry pi ) *
>>
>> I have tried:
>> Running 'pulseaudio' as my user
>> Running my app as my user
>>
>> I have not yet monkeyed with different pulseaudio configuration 
>> settings.
>>
>> Thanks in advance, this is a great library for headless art projects 
>> and my source will be available. I will certainly write up the 
>> results, probably for StackOverflow as an even more search-friendly 
>> source....
>>
>> -brian
>>
>> On 8/26/2019 7:31 AM, Brian Bulkowski wrote:
>>> Hi!
>>>
>>> Heaving read how bad headless is, and how it's "rarely" needed and 
>>> may not work, I was a bit blase about running my interactive art 
>>> installation from systemd.
>>>
>>> After all, systemd allows me to run as a user.
>>>
>>> When I run as a non-interactive user, I get a "pulseaudio can't 
>>> connect", which is an errno 6.  This happens from systemd, after 
>>> everything's started, I'm just debugging so I'm running my systemctl 
>>> start mylousy.service....
>>>
>>> From what I read here, the aversion to running as a service is 
>>> security, and if I run as a user everything should be fine, but it 
>>> is the connect call that failing.
>>>
>>> Regrettably I'm at a place with limited connectivity, but any tips 
>>> would be welcome, or at least for the next person who is trying to 
>>> run a perfectly reasonable headless installation.
>>>
>>> Thanks & Regards,
>>>
>>> -brian
>>>