[pulseaudio-discuss] Accessing audio as root

[Markus Rechberger]

On Mon, Jan 4, 2010 at 8:51 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Sun, 03.01.10 07:41, Bill Cox (waywardgeek at gmail.com) wrote:
>
>>
>> Hi, Colin.  I disagree that speech-dispatcher and speechd-up are
>> broken and need to be fixed.  speechd-up is a root daemon attached to
>> the /dev/softsynth device.  I see no utility in having multiple copies
>> of it.  Speech-dispatcher opens an IP port to act as a speech server
>> over the network.  It's kind of a silly feature, but why should I
>> second-guess the speech-dispatchers developers and break it?
>
> Why do you second-guess us, but not them?
>
> In the long run device access for root wont work anyway, for example,
> when you acre about more than ALSA kernel devices, such as bluetooth
> or other stuff that might need user supplied security credentials.
>
> audio output as root is broken.
>

it's not but it doesn't matter just about every other user has the same issue.
Root has full access to the hardware (eg. doing maintenance, testing
the hardware
modifying global settings etc.).

>> IMO, what's broken is PA.  I can't in Ubuntu get two copies running on
>> the same machine without borking the sound system.  If PA can't even
>> do it, why should I mangle all the accessibility apps out there by
>> making them try to follow PA's overly complex model?
>
> Works fine here. If two users log in then access to the audio device
> is handed over to the active user as soon as you switch to it and
> removed from now inactive user. Audio is automatically paused for
> inactive users and resumed as soon as they become active again.
>

We are fine with your idea but bring back compatibility to the old
audio system, some
users want it and need it.

>> This has to be a screaming violation of the KISS rule.  The sound
>> system is a bit complex.  Fine.  To use it, you need to make all
>> your apps complex?  Really?
>

agreed.

> First of all, PA is really not that complex in this area. We simply
> watch the permissions on the device nodes and close the device/pause
> playback if we loose access and reopen the device/resume playback if
> we get access again. From a high-level perspective there is nothing
> easier than that.
>
> Secondly, the whole udev/CK logic has originally been designed
> independantly of PA. If you thinkg that PA is overcomplex in this
> design, then I'd like to ask you to redirect your complains to the
> udev/CK folks.
>
>> The complexity has to be contained.  It can't keep leaking out of PA
>> into the rest of the system, making it more and more unstable as it
>> goes.
>
> That's FUD. And that's why I will ignore it.
>

it's not it's just a matter of which system someone is running and
what problem someone
is experiencing.
http://sundtek.de/support/pulseaudio.wav
Ubuntu 9.10, don't know how to reproduce it (sure it doesn't help but
how do you expect users
to debug issues which come up randomly after a while?)

Markus