[pulseaudio-discuss] Accessing audio as root

[Markus Rechberger]

On Fri, Nov 27, 2009 at 2:00 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Markus Rechberger at 26/11/09 15:32 did gyre and gimble:
>>>
>>> So really there are only two solutions here:
>>>  1. Bypass pulse and access the audio directly.
>>>  2. Run roots very own PA process and use it.
>>>  3. Run system-wide PA.
>>>  4. Run PA on top of some lower level mixer e.g. dmix.
>>>
>>> Now all of these have major flaws and disadvantages. 1 and 2 require
>>> hardware mixing which is not all that common these days so is totally out
>>> of
>>> the question. 3. Is nasty, requiring access rules to be pushed into user
>>> administration (e.g. adding users to the pulse-access group)[0], and also
>>> breaking SHM usage in IPC which adds huge overhead. 4. Adds lots of
>>> latency
>>> and totally breaks glitch free control of the sound hardware which has
>>> huge
>>> knock on effects for power savings and other important aspects.
>>>
>>
>> ok this sounds like PA breaks compatibility by design here...
>
> Pretty much yeah. This is simply not a use case we're focusing on.
>
>
>> we could move it to kernelspace too it's a driver.
>
> Do you read lkml? Not going to happen.
>

no, I meant our work not pulseaudio. We moved the entire video4linux
and DVB framework to userspace.
audio is directly handled by the driver in our case. And the driver
usually runs as root.
Right now we reconfigure pulseaudio with our installer to run as
systemwide process in order to support
root audio playback.

>> please do not break the default behaviour.
>
> Default behaviour? That's just what it's defined as... you are asking not to
> be *current* behaviour. To not break default behaviour is easy.. you just
> re-define "Default" :p
>
>> we do not necessarily run X11 on our systems either.
>
> So the use case you are now worried about is a user logging in to a text
> console, and starting a sound producing application (which launches pulse),
> either putting that app in the background (or using "screen" or similar
> apps) or exiting that program but then acting quickly before PA dies, then
> becoming root and launching a second sound producing application?
>
> This is a really, really, really niche use case!
>
> All other scenarios work fine due to console kit permission grants etc.
>
>

I think the explanation above gives you an insight about what we need actually.

>> If I'm logged in as root I'd like to have the control over the box
>> whatever happens.
>
> Sure, but like I said before if a user is using the physical hardware
> already, even root cannot always get magical access if it's currently
> blocked without killing the user process.
>
>> So getting a permission denied from mplayer when playing audio is not
>> a good way to go,
>> especially since it worked with alsa and oss.
>
> Doesn't work with oss over alsa - first process gets dibs. I've already
> explained why the pure alsa dmix approach (while very clever and nice by
> itself) will totally break other nice things we can do with regards to power
> savings etc. due to the glitch free system. So while you point out a
> "solution" here it has a distinct cost... personally, on balance, I thing
> it's more than worth the cost for the very very niche use case breakage.
>

I'm looking for an acceptable solution.

I do know that pulseaudio usually is not stable on almost all systems out there,
there are cases which seem to cause problems with PA, eg starving
audio.. this finally
triggers a mechanism in our driver which tries to kill PA and bypass
it afterwards..
Although I do think PA will become stable at some time so I'm
interested in having
it work a better way... we currently only use the pulseaudio simple
API but the PA system
reconfiguration is not what we want.

How about changing the group to the PA group temporary when trying to
use it as root for setting up the mapping?
Question here what's the best way to determine the group of the
running PA daemon?
Is there something comfortable available for this or do we have to
parse the proc/pid structure, using /etc/passwd,
a PA API call?

Markus