Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Ben Bucksch at 12/11/11 20:56 did gyre and gimble: On 12.11.2011 21:21, Colin Guthrie wrote: Ben Bucksch wrote: On 09.11.2011 11:56, Colin Guthrie wrote: Now consider two users on an accessible system: One is visually impaired the other is not - at the same time. OK, but that's really an unrealistic case now. No I meant two users on the system. Only one uses the machine at any given time. My point was mainly that the control over whether the sounds from the underlying services (be it mpd or some accessibility layer) should be user choice, not forced upon them. Yes, sure. And with pulse, that's trivial: *If* such a daemon really is running and disturbing, it's easy to silence via pavucontrol. Yes, assuming the daemon is connecting to the users PA daemon. mpd as a daemon shouldn't be forced upon any user Please check the scenario I outlined again (copied again below). That was a real case, of a friend who dropped pulseaudio, because that wasn't workable. With the design I outlined your friend wouldn't have had any problems. I'm wondering if I'm not explaining it correctly More realistic is: An average couple, he is a unix geek. He has a notebook and a tablet. The notebook is connected to speakers, running mpd for music. Tablet is running mpdroid and controls the mpd. The notebook has 2 users (but never at the same time), so the geek doesn't want to log in to any particular account just to listen music, but wants mpd to work irregardless of the logged-in user. There's no conflict, because if the music disturbs her, she'll just turn around and tell him to stop. Which, I think, will be true for almost all cases where you have 2 humans around the same computer at the same time. If you don't know mpd, please check it out. The whole idea is that I can control from several clients, but the playback is done by the server. And it's *really* cool, esp. combined with an Android tablet. I'm fully aware of how it works and as far the control and input stages go, that's perfectly fine. That doesn't mean that it is architecturally perfect. and I feel that having a system-wide daemon outputting sound regardless of who is logged in is fundamentally the wrong approach. In the scenario I envisage, you'd still have the central mpd process, and you'd still have mpd clients connecting to select what is played. The only difference is that rather than the daemon process actually actively outputting sound, it is separated into an mpd output agent process. This process needs to run and connect with he daemon to do the output stage. Any client could still log in and do the control/selection stuff, and any active output agent will simply and dumbly output the sound. Each user on the system that agrees to let mpd play will run the output agent as their own user (and this includes the gdm user whose participation in the mpd setup is a system administrator choice). It then thus connects to their own PA daemon and all is well in the world. I'd draw a diagram but I'm about to head out the house, but hopefully I've cleared up any confusion you have. It doesn't match the scearnio you painted 100% but IMO it gives full control by default but still gives individual users the right to opt out completely. As I said, this approach is something that applies generally beyond MPD and just sits on top of all the underlying security systems without having to turn PA into something it really shouldn't be (see all my previous mails about this) and something we'd be very widely criticised (for good reason) were we to implement. You have to appreciate that everyone's problem is the most important to them, but we, as an upstream project, have to consider a wide range of issues, use cases and problems. I think the design outlined meets all the practical needs of the typical mpd setup while not compromising anything regarding overall security and design of PA itself. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
On 13.11.2011 15:40, Colin Guthrie wrote: 'Twas brillig, and Ben Bucksch at 12/11/11 20:56 did gyre and gimble: The whole idea is that I can control from several clients, but the playback is done by the server. And it's *really* cool, esp. combined with an Android tablet. I'm fully aware of how it works and as far the control and input stages go, that's perfectly fine. That doesn't mean that it is architecturally perfect. and I feel that having a system-wide daemon outputting sound regardless of who is logged in is fundamentally the wrong approach. In the scenario I envisage, you'd still have the central mpd process, and you'd still have mpd clients connecting to select what is played. The only difference is that rather than the daemon process actually actively outputting sound, it is separated into an mpd output agent process. This process needs to run and connect with he daemon to do the output stage. Any client could still log in and do the control/selection stuff, and any active output agent will simply and dumbly output the sound. Each user on the system that agrees to let mpd play will run the output agent as their own user (and this includes the gdm user whose participation in the mpd setup is a system administrator choice). It then thus connects to their own PA daemon and all is well in the world. This doesn't allow the situation where you just start the machine, no user logged in (because it's acting as server), and you can play music with your tablet, loudspeakers connected to the computer. *That* is where the pulseaudio setup failed for my friend. It's *both* a squeezebox appliance (server, no user, no UI) and a desktop. And that's also my setup, just that my pulse server is the HTPC, so I don't run into it. Yes, this design is fundamentally at odd with that of pulseaudio as user daemon. But that doesn't mean the design of mpd is wrong. In my view: There's only one sound card (hardware), so there should be only one pulse server, which implies a system-wide pulse server should be used. That would be logical for me. You prefer different design, fine, but that doesn't mean the system-wide is broken. I'm just asking that the system-wide setup of pulse is properly supported, not just a step-child where you don't care when it's hurting. Ben ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
On 13.11.2011 15:40, Colin Guthrie wrote: 'Twas brillig, and Ben Bucksch at 12/11/11 20:56 did gyre and gimble: The whole idea is that I can control from several clients, but the playback is done by the server. And it's *really* cool, esp. combined with an Android tablet. I'm fully aware of how it works and as far the control and input stages go, that's perfectly fine. That doesn't mean that it is architecturally perfect. and I feel that having a system-wide daemon outputting sound regardless of who is logged in is fundamentally the wrong approach. In the scenario I envisage, you'd still have the central mpd process, and you'd still have mpd clients connecting to select what is played. The only difference is that rather than the daemon process actually actively outputting sound, it is separated into an mpd output agent process. This process needs to run and connect with he daemon to do the output stage. Any client could still log in and do the control/selection stuff, and any active output agent will simply and dumbly output the sound. Each user on the system that agrees to let mpd play will run the output agent as their own user (and this includes the gdm user whose participation in the mpd setup is a system administrator choice). It then thus connects to their own PA daemon and all is well in the world. This doesn't allow the situation where you just start the machine, no user logged in (because it's acting as server), and you can play music with your tablet, loudspeakers connected to the computer. *That* is where the pulseaudio setup failed for my friend. It's *both* a squeezebox appliance - i.e. server, no user, no UI - and a desktop. That should be possible, but it failed with pulse. And that's also my setup, just that my pulse server is the HTPC, so I don't run into a problem. Yes, this design is fundamentally at odd with that of pulseaudio as user daemon. But that doesn't mean the design of mpd is wrong. In my view: There's only one sound card (hardware), so there should be only one pulse server, which implies a system-wide pulse server should be used. That would be logical for me. You prefer different design, fine, but that doesn't mean the system-wide is broken. I'm just asking that the system-wide setup of pulse is properly supported. Ben ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Ben Bucksch at 13/11/11 17:38 did gyre and gimble: On 13.11.2011 15:40, Colin Guthrie wrote: 'Twas brillig, and Ben Bucksch at 12/11/11 20:56 did gyre and gimble: The whole idea is that I can control from several clients, but the playback is done by the server. And it's *really* cool, esp. combined with an Android tablet. I'm fully aware of how it works and as far the control and input stages go, that's perfectly fine. That doesn't mean that it is architecturally perfect. and I feel that having a system-wide daemon outputting sound regardless of who is logged in is fundamentally the wrong approach. In the scenario I envisage, you'd still have the central mpd process, and you'd still have mpd clients connecting to select what is played. The only difference is that rather than the daemon process actually actively outputting sound, it is separated into an mpd output agent process. This process needs to run and connect with he daemon to do the output stage. Any client could still log in and do the control/selection stuff, and any active output agent will simply and dumbly output the sound. Each user on the system that agrees to let mpd play will run the output agent as their own user (and this includes the gdm user whose participation in the mpd setup is a system administrator choice). It then thus connects to their own PA daemon and all is well in the world. This doesn't allow the situation where you just start the machine, no user logged in (because it's acting as server), and you can play music with your tablet, loudspeakers connected to the computer. Yes it does. I've mentioned several times that the login session, e.g. gdm etc. would be considered a user in this scenario. The same workings (if a gdm is not run) would apply for e.g. getty's etc too. But in this scenario it's up to the system administrator to say that the login user does or does not run the agent. After that, it's whichever real user who logs in that has the choice as to whether or not to run the agent. My first example was specifically about accessibility. In this case the login screen really needs to connect to the underlying accessibility framework so as to offer the less able user to login easily. I'm just asking that the system-wide setup of pulse is properly supported. This is fine. It's as supported as it needs to be. But as I've gone to pains to explain, it has fundamental limitations in design that limit it's usefulness. I genuinely believe that the approach I've outlined is a better model for supporting the kind of use cases you want, plus ensuring security and utilising all the other bits that fit very well in PA just now. I just think one of the aspects of this plan has not been clearly enough explained, so sorry about that. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Martin Steigerwald at 10/11/11 13:22 did gyre and gimble: Am Donnerstag, 10. November 2011 schrieb Ben Bucksch: Colin, first, thanks for your long, detailled answers! Just a short reply: On 09.11.2011 11:56, Colin Guthrie wrote: Now consider two users on an accessible system: One is visually impaired the other is not - at the same time. OK, but that's really an unrealistic case now. The blind guy needs the sound output, so likely he doesn't have somebody else working on the same machine at the same time. I also thought about this. How often is a per session setup really used? How are computers shared? I am not sure about numbers. Does anyone use the features of the one Pulseaudio daemon per session setup like muting audio output from one session when switching to another one? Yes, this is the standard setup and also how such things work on other operating systems like OSX and Windows when doing fast user swtiching which is what we're talking about here. I could imagine a family computer for this usecase where several people are logged in simulatenously. Then when the father does not switch off the audio, the daughter could just switch the session and do her voice chats. Precisely. It puts each user in control without relying on the father to come in from the garage just so he can unlock his session and hit pause in his media player before the daughter can go and call her friends. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
On 12.11.2011 21:21, Colin Guthrie wrote: Ben Bucksch wrote: On 09.11.2011 11:56, Colin Guthrie wrote: Now consider two users on an accessible system: One is visually impaired the other is not - at the same time. OK, but that's really an unrealistic case now. No I meant two users on the system. Only one uses the machine at any given time. My point was mainly that the control over whether the sounds from the underlying services (be it mpd or some accessibility layer) should be user choice, not forced upon them. Yes, sure. And with pulse, that's trivial: *If* such a daemon really is running and disturbing, it's easy to silence via pavucontrol. mpd as a daemon shouldn't be forced upon any user Please check the scenario I outlined again (copied again below). That was a real case, of a friend who dropped pulseaudio, because that wasn't workable. I have a similar setup, but no problem, because I have a dedicated HTPC machine that is always running, and always with the same user account. More realistic is: An average couple, he is a unix geek. He has a notebook and a tablet. The notebook is connected to speakers, running mpd for music. Tablet is running mpdroid and controls the mpd. The notebook has 2 users (but never at the same time), so the geek doesn't want to log in to any particular account just to listen music, but wants mpd to work irregardless of the logged-in user. There's no conflict, because if the music disturbs her, she'll just turn around and tell him to stop. Which, I think, will be true for almost all cases where you have 2 humans around the same computer at the same time. If you don't know mpd, please check it out. The whole idea is that I can control from several clients, but the playback is done by the server. And it's *really* cool, esp. combined with an Android tablet. Ben ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Am Donnerstag, 10. November 2011 schrieb Ben Bucksch: Colin, first, thanks for your long, detailled answers! Just a short reply: On 09.11.2011 11:56, Colin Guthrie wrote: Now consider two users on an accessible system: One is visually impaired the other is not - at the same time. OK, but that's really an unrealistic case now. The blind guy needs the sound output, so likely he doesn't have somebody else working on the same machine at the same time. I also thought about this. How often is a per session setup really used? How are computers shared? I am not sure about numbers. Does anyone use the features of the one Pulseaudio daemon per session setup like muting audio output from one session when switching to another one? I could imagine a family computer for this usecase where several people are logged in simulatenously. Then when the father does not switch off the audio, the daughter could just switch the session and do her voice chats. More realistic is: An average couple, he is a unix geek. He has a notebook and a tablet. The notebook is connected to speakers, running mpd for music. Tablet is running mpdroid and controls the mpd. The notebook has 2 users (but never at the same time), so the geek doesn't want to log in to any particular account just to listen music, but wants mpd to work irregardless of the logged-in user. There's no conflict, because if the music disturbs her, she'll just turn around and tell him to stop. Which, I think, will be true for almost all cases where you have 2 humans around the same computer at the same time. Well my girl friend still prefers to use the CD player anyway - I bet Amarok looks to be too complex to her, maybe a multimedia center does work better. And at home I have a dedicated Amarok playback machine. So for me its also: She tells me when she wants to hear something different while the laptop is playing. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Am Montag, 7. November 2011 schrieb Maarten Bosmans: Hi! I have two users on my laptop. When I start to playback sound from the session of the first user and then switch to the second user pulseaudio stops to play back sound from the first user. This way I also do not hear appointment reminders from the session thats currently not active unless I switch again. Correct. This is by design. I have removed Pulseaudio from my main machine now again. To be fair, sound playback via ALSA does not work in mutiple sessions in the moment too. If Amarok is playing on one session I can´t play audio from the second one. I thought that this would be mixed automatically. Maybe there was some asound.conf in place that I replaced my one for Pulseaudio. Thus at least this seems to need additional setup with ALSA too on my machine at the moment. Anyway, I can have Amarok playback music, while I work on my company´s user session and that was all I wanted and what Pulseaudio won´t give me easily. I might still followup the bugs I found on my Amarok playback machine, a ThinkPad T23, at home. Lets see. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Am Mittwoch, 9. November 2011 schrieb Martin Steigerwald: Am Montag, 7. November 2011 schrieb Maarten Bosmans: Hi! I have two users on my laptop. When I start to playback sound from the session of the first user and then switch to the second user pulseaudio stops to play back sound from the first user. This way I also do not hear appointment reminders from the session thats currently not active unless I switch again. Correct. This is by design. I have removed Pulseaudio from my main machine now again. To be fair, sound playback via ALSA does not work in mutiple sessions in the moment too. If Amarok is playing on one session I can´t play audio from the second one. I thought that this would be mixed automatically. Maybe there was some asound.conf in place that I replaced my one for Pulseaudio. Thus at least this seems to need additional setup with ALSA too on my machine at the moment. Easy enough: dmix is set by standard as of ALSA 1.0.9rc2 [1] but getfacl shows that only one of my users is added to the ACL list for device files in /dev/snd. Whyever... So its going to be the good old way around: I added both users to group audio. I removed them from there for the perfect pulseaudio setup. Now I get simultaneous audio on both sessions without a glitch. And frankly I don´t care whether thats by design or not. I even don´t care about the recording issue for these two users, cause they are both mine. A mailing list reader suggested a VM for the second user, but all I just want is two KDE sessions with audio simultaneously and now I just got want I wanted. Why use a VM when its not needed? I still hope that Pulseaudio can give me this by a simple configuration option one time. I stand by it that this is a perfectly valid setup and do not want to dictacted to organize my stuff differently by software or design. [1] http://alsa.opensrc.org/Dmix Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
On 09.11.2011 10:50, Martin Steigerwald wrote: Am Montag, 7. November 2011 schrieb Maarten Bosmans: When I start to playback sound from the session of the first user and then switch to the second user pulseaudio stops to play back sound from the first user. Correct. This is by design. I have removed Pulseaudio from my main machine now again. ... I can have Amarok playback music, while I work on my company´s user session and that was all I wanted and what Pulseaudio won´t give me easily. Tip, for you and others: If you want to separate stuff for security reasons, you can use a VM with kvm -soundhw es1370. kvm supports pulse and will redirect all the sound of the VM to your pulse server. Just set, under the kvm-starting user, ~/.pulse/client.conf with default-server = ..., and enable the pulse networking on the server, and you'll hear the Windows-Login-Sound from your pulse. The VM guest doesn't need to know about pulse. I find that awesome. For the pulse people: Please don't tell people that the problems they run into are by design. You'll have people running away, or even have quite negative feelings about pulse. Rather, fix the limitations, please. Ben ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Am Mittwoch, 9. November 2011 schrieb Ben Bucksch: On 09.11.2011 10:50, Martin Steigerwald wrote: Am Montag, 7. November 2011 schrieb Maarten Bosmans: When I start to playback sound from the session of the first user and then switch to the second user pulseaudio stops to play back sound from the first user. Correct. This is by design. I have removed Pulseaudio from my main machine now again. ... I can have Amarok playback music, while I work on my company´s user session and that was all I wanted and what Pulseaudio won´t give me easily. Tip, for you and others: If you want to separate stuff for security reasons, you can use a VM with kvm -soundhw es1370. kvm supports pulse and will redirect all the sound of the VM to your pulse server. Just set, under the kvm-starting user, ~/.pulse/client.conf with default-server = ..., and enable the pulse networking on the server, and you'll hear the Windows-Login-Sound from your pulse. The VM guest doesn't need to know about pulse. I find that awesome. Thanks for the hint. Its mainly for data separation, not for security. I trust my laptop setup enough to have two users running on it. And when its off the data is encrypted. I do use virtualization, like for example for the Cisco Anywhere VPN client thats messing with network configuration beyond sanity. For the pulse people: Please don't tell people that the problems they run into are by design. You'll have people running away, or even have quite negative feelings about pulse. Rather, fix the limitations, please. I am all for innovation. But only as far as it does not take features away that I got used to and really like. I see the point in per session setup, and I even think its suitable for many users. But as it is now, it doesn´t support my use case. I would even do not have any problem when there would still be two session based pulseaudio daemons just using dmixing for audio output and grabbing input for recording explicitely. Only then there would need to be some mechanism to decide which user gets recording. It could by on a case base, so that Pulseaudio grabs input sinks only on demand. And it should not be possible to record the dmixed audio output by any user. Each user may only record his own audio output. Maybe thats a workable idea? Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Ben Bucksch at 07/11/11 19:43 did gyre and gimble: On 07.11.2011 19:59, Maarten Bosmans wrote: I would load module-protocol-native-tcp with ip-acl=127.0.0.1. Then for other users set PULSE_SERVER=localhost. Yes, that's what I recommended a friend, too. Problem is: which pulse server is the main one and which one connects? Any user can log in first. Also, what do you do in cases of e.g. mpd running as daemon (by design) and needing to output sound, and GNOME running on the same machine. Note that a lot of pulseaudio depends on an active X11 session, including the dbus stuff, and bails if there isn't. Also note that many of the official disclaimers / stated problems of the system-wide solution apply when you enable a network port and do stuff as you suggest. May I recommend to officially support the system-wide solution and make it work well? I don't see another solution for multi-user systems and daemons. The term multi-user systems here is misleading. PA goes out of it's way to be multi-user friendly. What it does not do particularly well OOTB is multiple users at the same time, which, as stated, is by design. I do not want user A to login and play their Brittany Spears discog and lock their station meaning that I have to turn off all sound. I do not want user A to lock their station while running a program that would let them eavesdrop on my private VoIP calls. Now keep in mind that this method of working is NOT really a PA design anyway - yes the PA design fits in with this, but its the underlying layers of the system that set the permissions in the first place. Whether it's console-kit (rapidly becoming obsolete, but in use currently) or systemd-logind, both ultimately work with udev to ensure the ACLs for only the appropriate (i.e. active) user are written to the audio device nodes. The fact that Linux does not have a revoke() system to pull device access away from people meant that if a user had the audio device open when his privileges were revoked, he could still output sound. That's a bad situation but PA fixes that by noticing the permission changes and being a good citizen. But once closed, the user who has no writes on the device should not be able to play. Plain and simple, that's what the lower level permission system imposes. Now another thing that also works very well in the multi-user domain is mutli-seat systems. If you have systems where two people can login at the same time with separate keyboards, pointers and screens, then systemd is very capable of defining seats and allocating e.g. PCI devices or USB ports to each seat. PA will honour this and give each user access to his own USB or PCI sound card. While the practicalities are different, you cannot share single screen for graphics in this case, and sound is pretty much in the same boat. 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. Needed use cases are still possible. You have to do more work yourself. Depending on how distros package things, you may or may not have to do much more then tick a box in a GUI, but that is very much beyond our control. You have to run a system-wide daemon. It's not something we actively support because this use case is very much in the minority and it causes a lot of headaches and unnecessary overhead - one of the primary disadvantages is the inability to support ho tplugging properly (because any kind of system-wide process will totally ignore the users carefully configured seat configurations etc), causes obvious security problems relating to eavesdropping and also cannot use SHM memory and thus causes a lot more overhead when dealing with client-server communications - i.e. you need to copy the audio data over the wire. So while conceptually it's easy to say you should support it, it's easy you end up having to build a whole security manager into PA itself rather than rely on underlying systems. If we were to ever do that we'd get an equally vocal group of people saying why the hell are you building security policy into PA, that's totally not it's job you idiots. So I say this: If you want system-wide PA, use system-wide PA. We do not recommend it, but it doesn't mean we'll sneak into your house at night and kill your kittens. You have extra overhead which may affect latency in games or voip and you have to make sure your users are in the pulse-access group. You might have to tweak certain files to get bluetooth working, you may not be able to use certain funky features such as network support etc. (tho' it should still be possible to teach SSH how to deal with PA natively -
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Martin Steigerwald at 07/11/11 21:49 did gyre and gimble: Am Montag, 7. November 2011 schrieb Maarten Bosmans: 2011/11/7 Martin Steigerwald m...@teamix.de: Hi! Hi Maarten, hi, Before using Pulseaudio sound from both sessions has been played simultaneously with Phonon + Xine. Now I am using Phonon + GStreamer, but I bet stopping the audio comes from Pulseaudio. I read about system-wide mode. But first I shouldn't use it and second it doesn't solve this issue anyway, cause sound is still stopped. Maybe I missed setting autospawn on clients to off - cause I saw three pulseaudio daemons, one system-wide and two from the users -, but I do not like messing around with my Pulseaudio setup anymore - especially when its not recommended. Reason for trying Pulseaudio for me mostly was cause thats whats coming with Debian KDE standard install out of the box in the meanwhile. So whats the official way to achieve what I had before out of the box? The default per-session handling of audio makes sense for unix users being used by different human users on a shared computer but it does not make too much sense for my use case. I would load module-protocol-native-tcp with ip-acl=127.0.0.1. Then for other users set PULSE_SERVER=localhost. Could this work with a three server setup: 1) one system-wide on 127.0.0.1 2) two session based ones that communicate with the system wide one? This ins't really what was suggested. Basically for ease of setup (although this is a loosely defined term!), Maarten was suggesting that the first user (one who is maybe pretty much always logged in anyway) just runs the only PA server, but runs it as a per-user daemon as normal. But that user customises their default.pa: e.g. create a ~/.pulse/default.pa containing: .include /etc/pulse/default.pa load-module module-protocol-native-tcp ip-acl=127.0.0.1 You should also do touch ~/.pulse/client.conf (I've not checked the syntax but I think it's right). Then for the other users write a /etc/pulse/client.conf with: default-server = localhost autospawn = no The primary user's personal client.conf overrides these settings, but all other users get them. You may also need to disable the XDG scripts from running at login (the start-pulseaudio-* scripts can't remember if this is handled or not - either way the fix is simple, just edit the scripts and put a [ $USER = yourprimaryuser ] || exit near the top of them. You also need to make sure that the primary user is in the audio group such that they can always access the sound hardware. With this setup, provided your primary user is always logged in, everyone will have sound. Or preferably not over TCP/IP at all but using unix sockets? Your primary user will go via unix sockets and get the benefits of SHM for memory transfer (you should therefore run mpd as this user if you run it). The other users would use TCP. In a full system-wide setup, all users could use unix sockets, but none could use SHM for memory transfer, so there is still a tradeoff. Would this then solve the security issues mentioned on http://www.pulseaudio.org/wiki/WhatIsWrongWithSystemMode No. The system is wide open to abuse from all users. Please tell me when I am completely off track with that idea. Then feel free to skip answering the more detailed questions below. Security: Much like the X server as soon as you are authenticated you have complete control of the sound server, no further per-object access checks are done. That should be solved, shouldn´t it? A networked server should look at permissions when other Pulseaudio daemons access it, right? But then it is needed to make sure, that the 127.0.0.1 or unix socket is the only way, the per session servers can access the system wide one. So users shall not be in the group for accessing the system wide pulseaudio server directly. Not quite sure what you're suggesting here but obviously for TCP connections there is no concept of user unless you make PA support e.g. SASL based authentication or something crazy like that (and please see my previous, much longer explanation of things in reply to Ben's email for why we'd get massively criticised if we started adding that kind of junk to PA!). For sockets, we already have a pulse-access group that is needed to be able to access it via a system-wide socket. And as above, the pulse user running the PA deamon would need to be in the audio group. When in system mode, module loading after startup is disabled for security reasons, which means: no hotplug handling in system mode Well as thats an option I could enable it again, given that the security issues are solved. With the above suggestion of not using a real system-wide mode, just a primary user mode, there would be no problem with module loading etc. as that user is just a regular session... the security issues of eavesdropping etc. as ever present of course. When in
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Martin Steigerwald at 09/11/11 10:28 did gyre and gimble: Easy enough: dmix is set by standard as of ALSA 1.0.9rc2 [1] dmix is good system but we've moved on from there. If you are using a pure alsa setup I'd certainly recommend it, but it does strange things to sample rates etc. but getfacl shows that only one of my users is added to the ACL list for device files in /dev/snd. Whyever... It's likely (at present due to the information in console-kit. See ck-list-sessions. Only one user is ACTIVE than that user will get ACL access to audio (and numerous other devices too) via udev-acl. In the future, this will be done instead by systemd-logind as console-kit is deprecated. So its going to be the good old way around: I added both users to group audio. I removed them from there for the perfect pulseaudio setup. Now I get simultaneous audio on both sessions without a glitch. And frankly I don´t care whether thats by design or not. I even don´t care about the recording issue for these two users, cause they are both mine. That's fine. If this system works for you and you can happily use the devices you own and run the apps you want, then it's all good. I think it's still a fundamentally flawed system and we cannot design for this use case where security and access is good enough or with unnecessary layers and admin overheads. A mailing list reader suggested a VM for the second user, but all I just want is two KDE sessions with audio simultaneously and now I just got want I wanted. Why use a VM when its not needed? I think that's massively overkill. I still hope that Pulseaudio can give me this by a simple configuration option one time. I stand by it that this is a perfectly valid setup and do not want to dictacted to organize my stuff differently by software or design. I think this is the problem many systems face. We try to design both the audio and all plumbing layers in Linux to deal with a wide variety of situations in a robust and secure manner. That means that some setups will not work, that's the trade off. People don't want to compromise their configuration for good design and that's fine. It's Free Software after all, it's your right. But you also have to consider that the path you are taking is your own and thus the problems you encounter will have to be solved by yourself and a lot of the time when you ask people for support, you'll be given the it's not supported response. That's just the way it goes. If you are happy with that then, the best of luck to you :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Martin Steigerwald at 09/11/11 10:43 did gyre and gimble: I would even do not have any problem when there would still be two session based pulseaudio daemons just using dmixing for audio output and grabbing input for recording explicitely. Only then there would need to be some mechanism to decide which user gets recording. It could by on a case base, so that Pulseaudio grabs input sinks only on demand. And it should not be possible to record the dmixed audio output by any user. Each user may only record his own audio output. Maybe thats a workable idea? It's possible. Just configure the default.pa to use dmix for it's alsa sink, and then ensure that you set the profile for the udev-detected card for each user to an input only profile such that it doesn't create a sink too. Of course dmix adds overhead, messes about with timing, and screws up sample rate conversion (and uses the shitty quality resamplers too), but other than that it would work OK. Unless the card supports hardware mixing, the recording would only work for the first user to get it as the other tasks would fail. This is of course a hideous setup with horrible connotations for handling gracefully in UIs etc the cases when the audio doesn't work... It's certainly not something I'd be able to recommend with a straight face. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Colin, first, thanks for your long, detailled answers! Just a short reply: On 09.11.2011 11:56, Colin Guthrie wrote: Now consider two users on an accessible system: One is visually impaired the other is not - at the same time. OK, but that's really an unrealistic case now. The blind guy needs the sound output, so likely he doesn't have somebody else working on the same machine at the same time. More realistic is: An average couple, he is a unix geek. He has a notebook and a tablet. The notebook is connected to speakers, running mpd for music. Tablet is running mpdroid and controls the mpd. The notebook has 2 users (but never at the same time), so the geek doesn't want to log in to any particular account just to listen music, but wants mpd to work irregardless of the logged-in user. There's no conflict, because if the music disturbs her, she'll just turn around and tell him to stop. Which, I think, will be true for almost all cases where you have 2 humans around the same computer at the same time. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
2011-11-09 12:19, Colin Guthrie skrev: 'Twas brillig, and Martin Steigerwald at 07/11/11 21:49 did gyre and gimble: Am Montag, 7. November 2011 schrieb Maarten Bosmans: 2011/11/7 Martin Steigerwaldm...@teamix.de: Hi! Hi Maarten, hi, Before using Pulseaudio sound from both sessions has been played simultaneously with Phonon + Xine. Now I am using Phonon + GStreamer, but I bet stopping the audio comes from Pulseaudio. I read about system-wide mode. But first I shouldn't use it and second it doesn't solve this issue anyway, cause sound is still stopped. Maybe I missed setting autospawn on clients to off - cause I saw three pulseaudio daemons, one system-wide and two from the users -, but I do not like messing around with my Pulseaudio setup anymore - especially when its not recommended. Reason for trying Pulseaudio for me mostly was cause thats whats coming with Debian KDE standard install out of the box in the meanwhile. So whats the official way to achieve what I had before out of the box? The default per-session handling of audio makes sense for unix users being used by different human users on a shared computer but it does not make too much sense for my use case. I would load module-protocol-native-tcp with ip-acl=127.0.0.1. Then for other users set PULSE_SERVER=localhost. Could this work with a three server setup: 1) one system-wide on 127.0.0.1 2) two session based ones that communicate with the system wide one? This ins't really what was suggested. I haven't followed this thread closely, but I think this is a real use case and thus something we should officially support, and just not some very sparse but vocal minority. For me, I'm imagining something like a GUI where you can consciously assign one or more cards to be system-wide instead of user-wide. That would in turn control consolekit/systemd and possibly other stuff that needs to be done to ensure that this card is to be used by the pulse user instead of the current user. We would also set up a system-wide instance for this card. The user-wide pulseaudio would be set up to talk to the system-wide one if present (presumably through a protocol-native tunnel? There are so many different ways of talking that I don't remember if there is a better one). Sure, the user would have to live with no SHM support - in most cases I assume this overhead would be quite neglible. Sure, recording can be eavesdropped, but if the user has made that choice in the first place, that would be a feature. This obviously needs integration with other projects and downstream distros, and trying to think with both hats on, I think PA upstream is better off with trying to make some recommendations for this use case, as the alternative would be to have distros doing things on their own and then being beat up by PA for doing things the wrong way. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
2011/11/7 Martin Steigerwald m...@teamix.de: Hi! I have two users on my laptop. When I start to playback sound from the session of the first user and then switch to the second user pulseaudio stops to play back sound from the first user. This way I also do not hear appointment reminders from the session thats currently not active unless I switch again. Correct. This is by design. Before using Pulseaudio sound from both sessions has been played simultaneously with Phonon + Xine. Now I am using Phonon + GStreamer, but I bet stopping the audio comes from Pulseaudio. I read about system-wide mode. But first I shouldn't use it and second it doesn't solve this issue anyway, cause sound is still stopped. Maybe I missed setting autospawn on clients to off - cause I saw three pulseaudio daemons, one system-wide and two from the users -, but I do not like messing around with my Pulseaudio setup anymore - especially when its not recommended. Reason for trying Pulseaudio for me mostly was cause thats whats coming with Debian KDE standard install out of the box in the meanwhile. So whats the official way to achieve what I had before out of the box? The default per-session handling of audio makes sense for unix users being used by different human users on a shared computer but it does not make too much sense for my use case. I would load module-protocol-native-tcp with ip-acl=127.0.0.1. Then for other users set PULSE_SERVER=localhost. Best way would be to tell pulseaudio explicetely when some Unix users may play simultaneously. Ideally it should still not allow recording audio streams from each other user. But for now I would be fine with a global option. This recording thing is, among other things, one of the reasons multiple users aren't allowed to connect to eachothers pulse daemon by default. I found nothing on the wiki on that. And nothing really obvious via search engine either. I only found out that I am not the only user puzzled by this new different behavior to what I was used to before. Thanks, Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
On 07.11.2011 19:59, Maarten Bosmans wrote: I would load module-protocol-native-tcp with ip-acl=127.0.0.1. Then for other users set PULSE_SERVER=localhost. Yes, that's what I recommended a friend, too. Problem is: which pulse server is the main one and which one connects? Any user can log in first. Also, what do you do in cases of e.g. mpd running as daemon (by design) and needing to output sound, and GNOME running on the same machine. Note that a lot of pulseaudio depends on an active X11 session, including the dbus stuff, and bails if there isn't. Also note that many of the official disclaimers / stated problems of the system-wide solution apply when you enable a network port and do stuff as you suggest. May I recommend to officially support the system-wide solution and make it work well? I don't see another solution for multi-user systems and daemons. 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. Please note: I am a fan of pulse, since several years. But I have a really hard stance defending it. Ben ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Am Montag, 7. November 2011 schrieb Maarten Bosmans: 2011/11/7 Martin Steigerwald m...@teamix.de: Hi! Hi Maarten, hi, Before using Pulseaudio sound from both sessions has been played simultaneously with Phonon + Xine. Now I am using Phonon + GStreamer, but I bet stopping the audio comes from Pulseaudio. I read about system-wide mode. But first I shouldn't use it and second it doesn't solve this issue anyway, cause sound is still stopped. Maybe I missed setting autospawn on clients to off - cause I saw three pulseaudio daemons, one system-wide and two from the users -, but I do not like messing around with my Pulseaudio setup anymore - especially when its not recommended. Reason for trying Pulseaudio for me mostly was cause thats whats coming with Debian KDE standard install out of the box in the meanwhile. So whats the official way to achieve what I had before out of the box? The default per-session handling of audio makes sense for unix users being used by different human users on a shared computer but it does not make too much sense for my use case. I would load module-protocol-native-tcp with ip-acl=127.0.0.1. Then for other users set PULSE_SERVER=localhost. Could this work with a three server setup: 1) one system-wide on 127.0.0.1 2) two session based ones that communicate with the system wide one? Or preferably not over TCP/IP at all but using unix sockets? Would this then solve the security issues mentioned on http://www.pulseaudio.org/wiki/WhatIsWrongWithSystemMode ? Please tell me when I am completely off track with that idea. Then feel free to skip answering the more detailed questions below. Security: Much like the X server as soon as you are authenticated you have complete control of the sound server, no further per-object access checks are done. That should be solved, shouldn´t it? A networked server should look at permissions when other Pulseaudio daemons access it, right? But then it is needed to make sure, that the 127.0.0.1 or unix socket is the only way, the per session servers can access the system wide one. So users shall not be in the group for accessing the system wide pulseaudio server directly. When in system mode, module loading after startup is disabled for security reasons, which means: no hotplug handling in system mode Well as thats an option I could enable it again, given that the security issues are solved. When in system mode, shared memory data transport is disabled for security reasons, which means: much higher memory usage and CPU load in system mode Same as above. The module-xxx-restore modules maintain state that is inheritely user specific, but when run in system mode is shared between users. I do not understand this one. Security: there are no size limits on state data, which enables users to flood /var unless you employ quotas on the pulse user Why? Security: all users that have access to the server can sniff into each others audio streams, listen to their mikes, and so on. This shouldn´t be possible with a networked system wide server, be it via TCP/IP or unix sockets. Right? When in system mode you also lose a lot of further functionality, like the bridging to jack, to rygel (upnp), to X11, to ckit, and so on What are the benefits of these? And which ones of these would be lost. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
