[pulseaudio-discuss] Accessing audio as root

[Colin Guthrie]

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

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


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

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]