Hi Maarten and Ben, hi *, Am Montag, 7. November 2011 schrieb Ben Bucksch: > > This recording thing is, among other things, one of the reasons > > multiple users aren't allowed to connect to eachothers pulse daemon > > by default. > > Exactly. But Martin and me now stated a few usecases where this is > *needed*. Saying "it's not recommended" and "yes, we know it's > insecure" doesn't solve the actual problem. If that's the result of > the design, then the design is obviously wrong and needs to be > revised. When I set off the hat of a user, frankly I do not care much about the implementation details or design. Okay, maybe I want it to be quite secure, especially regarding that recording thing, but how it is made secure does not interest me. All I see that without Pulseaudio, just using Phonon what I want to achieve works out of the box - while I believe, correct me if I believe wrong, one user could still not record something from the other user in that case. But with Pulseaudio it seems to be disallowed by design. I do not care whether Pulseaudio runs system wide or not, but I really like to see a solution for the usecase I outlined that works in any way of session start order. Technical to me it would make sense to have one system wide daemon doing the audio output and two session specific ones communicating with the system wide one. Then the system wide daemon can make sure of security issue by disallowing insecure stuff, while also apply policies like 1) I want to hear audio from user sessions foo and bar simultaneously while 2) user session baz should be separate. Recording would always be one session at a time only - at least for one input source. Just an idea. Maybe thats not feasible for good reasons I don?t know... and it seems it would add yet another layer of complexity and possibly latency. So or so I think the *design* of Pulseaudio should take care of this usecase and other usecases that need mixing audio *output* from different sessions. Cause I think it a valid usecase and from what I looked up with $searchengine I am not the only one who likes to have that. Frankly, I think when thats not possible, when Pulseaudio is to stay one session at a time only, I think I drop Pulseaudio again. I dropped it before once already due to the usb_set_interface_failed issue I didn?t want to invest more time in back then while Lennart offered to follow up on this and kindly asked me for some more information (ticket #926). Now I am interested in following up on this and also invest time into reporting another bug I found recently. With that same M-Audio Sonica Theater USB sound card on resume or after disconnecting and connecting the sound card - given that #926 does not trigger - Pulseaudio sets the volume of the one channel - my hifi says the left, but I AFAIR alsamixer says the right, maybe I mixed up audio cabling - to zero or it doesn?t initialize it to the proper volume. Anyway result is one speaker is quiet. I have to use alsamixer -c1 to correct it so that I hear both speakers again. So I have three problems after giving Pulseaudio another chance - I installed it on three laptops -, and I just admit that I find it quite frustrating when all I want is *just* listen to audio. Actually I try to like Pulseaudio cause it seems to be the default in Debian for a standard KDE install and when it works it seems to give quite good audio and jitter-free output. I still like to follow up on these bugs, but when in the end Pulseaudio turns out to be not suitable for one of my usecases, I am not sure whether I like to invest that time cause I prefer a uniform audio setup on all of my machines. I fully respect that it is your decision on how to design your software. When one of my usecases does not fit in I can just use something else. And while I believe I am not the only one with that use case, I might just be in a minority. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7