[pulseaudio-discuss] Accessing audio as root

[Markus Rechberger]

On Wed, Dec 23, 2009 at 1:49 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 23.12.09 13:16, Markus Rechberger (mrechberger at gmail.com) wrote:
>
>> > Right. It is innovative to carry on with the brokeness we always had
>> > just because we always had it and not because we would ever think
>> > about the brokeness and fix it? Is that what you think?
>>
>> Right, we had /etc/group for setting up the permissions pulseaudio breaks this
>> behaviour even with the Alsa compat library.
>
> Group-based access control is too limited for controlling access to
> seats in a multi-session environment.  That's why we have extended
> this with mechanisms like ConsoleKit and PolicyKit.
>
>> Sorry this behaviour is just broken, Pulseaudio should not be part
>> of any distribution until a certain level of compatibility is
>> reached.  compiz is optional it's easily possible to enable or
>> disable it.
>
> I guess we have to agree to disagree here.
>
> ConsoleKit (which is at the core of the multi-session support on our
> desktops now, including in PA) has been designed 3 years ago and
> pushed ino all distributions. It's the wrong time to whine about that
> now, and to me. If you think the whole CK design is an abomination
> then you are welcome to, but I'd prfer if you'd take that complains
> somewhere else.
>
>> The recommendation to use system mode is also a failure, why should
>> someone reconfigure the entire audio system on a distribution?
>
> If you run things headless/in a server you have to configure
> things. Surprise surprise...
>
> Also, let me point out that dmix does not support simultaneous output
> of streams from multiple users simultaneously either by default, for
> security reasons. You can enable that, but you have to configure that
> manually and it comes with a big yellow warning sign. This means that
> PA and ALSA dmix are really not that different in this respect. PA
> will make use of audio devices it has access to. ALSA dmix can do the
> same. As long as one user accesses a PA device it is blocked for all
> other users, which is very much like with ALSA dmix. The only
> difference is that on ALSA dmix after the user stopped using the
> device it is immediately accessible to othre users again, while in PA
> there is a 1s timeout. Not that big a difference.
>
> I'd prefer if you'd get your facts right before you start whining.
>
>> We have deployed alot devices which depend on audio nowadays at
>> certain b2b customers, guess how many are using pulseaudio? --
>> exactly noone. After talking to engineers everyone feels like PA is
>> just a pain, and by forcing your ideas which break the default
>> behaviour this situation will not improve.
>
> I dont force anything. It's Free Software. Take it or leave it. If you
> don't like it then you are entitled to that, but I find it kinda
> annoying if you then whine on our mailing lists, and start demanding
> things. That's not how it works. I am interested in constructive
> feedback but not at all being accused of "forcing". And if we disagree
> on something then please accept that. I have explained why we do
> things the way we do. And unless you have a better approach and some
> code to show I am pretty good at simply going on with what I do.
>
>> I'd rather like to see a clear statement why it is currently not
>> working, so someone can get onto that topic and fix it. If you want
>> to block it for other users add a configuration option for it but
>> again don't break the default behaviour
>
> Did you read any of the emails I wrote in this thread?
>
> if not, try it!
>

You're certainly good at ignoring bugreports your way, instead of
finding solutions
to fix it up.
Markus