[pulseaudio-discuss] Accessing audio as root

[Markus Rechberger]

On Fri, Nov 27, 2009 at 2:33 PM, Markus Rechberger
<mrechberger at gmail.com> wrote:
> 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.
>

http://support.sundtek.com/index.php/topic,4.0.html

maybe this can give an additional insight...

Markus
>> 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
> applications,
> 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.
>
> Markus
>