[pulseaudio-discuss] Accessing audio as root

Markus Rechberger mrechberger at gmail.com
Thu Nov 26 22:33:58 PST 2009

On Fri, Nov 27, 2009 at 2:25 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> pe, 2009-11-27 kello 13:08 +0800, Markus Rechberger kirjoitti:
>> 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).
> These are my thoughts based on this description (they may not make sense
> if there are additional details that make things more complicated):
> The product should provide kernel drivers that create a few devices: for
> digital TV you provide a DVB device, for FM radio you provide an ALSA
> capture device, and if the device also does analog TV, I'm not sure how
> that is usually handled - is it a v4l device for video and an ALSA
> capture device for sound?

it's entirely userspace based, as a second feature please note that we are able
to set up virtual devices (eg. streaming data from the network and
emulating devices)
So the audio input can either come from USB or from the network.

> You apparently want to make sure that there are easy ways to actually
> use those devices, so you write some playback software that utilizes the
> standard DVB, v4l and ALSA interfaces that your kernel driver has
> provided. The user is free to use any other software instead of yours,
> thanks to the standard hardware interfaces. Your playback software
> shouldn't be tied in any way to your hardware, except for special
> hardware features that can't be exposed in a standard way (or if you
> really just don't want to make the software interoperable with other
> vendor's hardware).

no it's a full virtual driver, it supports existing DVB and analog TV
The entire framework is based in userspace.
Linux multimedia support is currently quite a mess, default TV
applications across
all distributions mostly cannot handle audio by themself, this is why the driver
takes care about it. Aside of that when someone sets up FM radio through
the webinterface the daemon will run as root (either using a virtual
device through
the network or a physical one attached to the USB bus).

> Let's consider local (non-networked) use first. In this case I don't see
> why your software should run as root. Provide a normal application that
> runs under the user that starts it.
> In the networked case your software needs to act as a server, and
> servers often are not associated with a user session. Here running as
> root makes sense, except that it doesn't - please run your server under
> a special-purpose user for security reasons. Anyway, here you're going
> to run into problems with PulseAudio. I think that reconfiguring
> PulseAudio to run in the system-wide mode makes sense, after notifying
> the user and offering a way to restore the configuration (I hope this is
> feasible).
> That's what I think, I'm not sure if it helps any...

this is all just a workaround to  fix something that pulseaudio
breaks.. I'd really
prefer to have something that works..
When temporary changing over to the PA group the memory mappings
should be possible,
shouldn't it? I won't get around to check this before the end of next
week actually...

PA could handle this in the PA simple library. The only exception that
has to be made
is for root and noone else..
The topic should be how to fix pulseaudio instead of how to work
around the PA breakage.


More information about the pulseaudio-discuss mailing list