[pulseaudio-discuss] Accessing audio as root

[Colin Guthrie]

'Twas brillig, and Markus Rechberger at 26/11/09 18:13 did gyre and gimble:
>>> 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. 

Ahh right, sorry :)

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

Not sure I really follow here... As a general rule I doubt the kernel 
folks would want to move stuff that can be done in userspace into the 
kernel tho'.

> Right now we reconfigure pulseaudio with our installer to run as
> systemwide process in order to support
> root audio playback.

I'm not really sure that is a good idea. Unless this is done on some 
kind of specialist distro, I'd certainly be pretty pissed of as a user 
if this was done behind my back. Like I say using system-wide has lots 
of disadvantages and is generally not supported by us upstream in any 
official capacity. The lack of SHM means there is a lot of data copied 
around (instead of being predominantly zero-copy) and the onus is moved 
ot the user with regards to who is allowed access (although I don't see 
any reason why we cannot use console-kit's active state (plus special 
exemption for root) under system-wide mode, thus doing away with the 
need for checking that users are in pulse-access group. We would also 
need to check the streams belonging to the users and cork them etc if 
that user becomes inactive. Likewise we should only let the API report 
back on the users own streams and not show those of other users - all in 
all this a quite a lot of work but it would make system-wide a whole lot 
less ugly IMO - although I could easily be missing some major points 
(although the SHM thing is very much a major point anyway AFAIK).


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

I've been using PA exclusively for about 2 years. I have to say that it 
really doesn't give me any problems in this regard. Some programs 
interact in a bad way, but most of those problems have been ironed out now.

I really don't think that drivers should try and kill PA and by pass it 
etc. This is just ugly. If PA causes a major problem for your driver, 
just refuse to work when PA is running or use pasuspender or similar 
approaches.

Either that or find out why PA is failing and help fix the problem in 
the right place.

Adding workarounds such as this will only ever lead to problems and 
confusion. Problems should be fixed in the right place.

> we currently only use the pulseaudio simple
> API but the PA system
> reconfiguration is not what we want.

Indeed, I really think that is a bad idea. I certainly wouldn't want 
this happening behind my back when I install a package.

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

Nah this is doomed to fail as /etc/passwd is just one user 
authentication mechanism of many. My users are stored in LDAP for example.

This approach still requires system-wide mode and I think you should 
look for a solution at the user level.

What is it ultimately that a user does with your software? How do they 
interact with it? When does it work? (e.g. when user is logged in or not).

Perhaps with a bit of background here myself (and other users on the 
list) can come up with some ideas?

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/]