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! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4