[pulseaudio-discuss] Accessing audio as root
gmane at colin.guthr.ie
Thu Nov 26 10:00:10 PST 2009
'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), 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
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss