[pulseaudio-discuss] Accessing audio as root

[Markus Rechberger]

On Fri, Nov 27, 2009 at 7:02 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> '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 have been working with it for a year now with PA Simple and it has
been unstable
on most systems. An issue (as pointed out) seems to be if audio is
starving occasionally
the audio input comes from a live signal.

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

I think you got the point here..

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

I'm not sure how the PA daemon works right now but how about an API
command for retrieving the currently running user?
The PA simple lib could transparently use those returned values.

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

It works when the user is logged in or not.
The device supports TV (+Audio), and just simple FM Radio.
It is possible to remotely access this device (when configured to do so).
We're about to release a webfrontend for it so you can tune FM radio
through a website in your homenetwork (the network configuration needs
to be enabled explicitly by the user).

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

The driver which retrieves the raw audio samples runs as root, it just
directly tries
to play back those audio samples, but with pulseaudio it usually
doesn't wor without
reconfiguring it. (Note it works with OSS and Alsa by default).

Markus