Re: [pulseaudio-discuss] system-wide daemon
On Thu, Feb 11, 2010 at 12:29 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 10.02.10 09:59, Markus Rechberger (mrechber...@gmail.com) wrote: this is another wrong assumption, libusb uses raw USB access, if every user would have access to USB some devices might be damaged. Sane would need to be serverbased, full raw access to the usb bus would seriously be a security risk (imagine RAW USB access to a USB harddisk). This is nonsense. Since ages we by default add ACLs for the console user for libusb devices for cameras, scanners, and so on. That too works via udev-acl. Lennard, don't spread nonsense around, if you have raw access to a camera there might be the possibility to update the firmware and damage the device. If you would have little experience with hardware you should know about that. Your ACL/libusb restriction won't make this situation better it's still a security risk. Although just drop libusb as an example. Markus You are spreading FUD and lies. You are annoying. And are stealing my time. I'd prefer if you'd waste other people's time, and stop lighting up the flames of this flamewar over and over again. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 16.02.10 20:48, Markus Rechberger (mrechber...@gmail.com) wrote: Lennard, don't spread nonsense around, if you have raw access to a camera there might be the possibility to update the firmware and damage the device. If you would have little experience with hardware you should know about that. Your ACL/libusb restriction won't make this situation better it's still a security risk. Although just drop libusb as an example. Markus Marcus, then you better run quickly and complain to the udev folks, because they have been shipping udev with libusb devices accessible to console users sine about forever. Just plug in a USB scanner on a reasonably new Linux machine and run ls -al /dev/bus/usb/*/*. Then, look out for the + in the permissions column and run getfacl on that file, and you'll see that the logged in user may access the device node. But all of this has nothing to do with PA. So please go away, and complain elsewhere. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 16, 2010 at 10:17 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 16.02.10 20:48, Markus Rechberger (mrechber...@gmail.com) wrote: Lennard, don't spread nonsense around, if you have raw access to a camera there might be the possibility to update the firmware and damage the device. If you would have little experience with hardware you should know about that. Your ACL/libusb restriction won't make this situation better it's still a security risk. Although just drop libusb as an example. Markus Marcus, then you better run quickly and complain to the udev folks, because they have been shipping udev with libusb devices accessible to console users sine about forever. Just plug in a USB scanner on a reasonably new Linux machine and run ls -al /dev/bus/usb/*/*. Then, look out for the + in the permissions column and run getfacl on that file, and you'll see that the logged in user may access the device node. Sure but this doesn't mean that it's right and is a security issue. It's like making CPU levels obsolete just because someone made the mistakes to run everything at Kernellevel. Almost all available USB TV Tuners use to run with a firmware nowadays, even by loading the wrong firmware into a chip a chip can blow up. If every user has the possibility to access devices at a raw level (not at a defined API level) ...everyone can do that. But all of this has nothing to do with PA. Indeed, but this ACL example came up by you guys, so you should better learn that this is not always the correct way. With your example this even turns out to be a security risk. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10.02.10 18:49, Jeremy Nickurak (pulseaudio-disc...@trk.nickurak.ca) wrote: A question about the console-kit approach, where the user physically near the sound hardware is the person that gets to use it... A favorite trick of mine is to ssh into a machine, and use the sound hardware there to announce some kind of event. It might be an alarm to wake up a family member, or a remotely-generated event alert. It might not be SSH, it might be a cron job, or a CGI... Assuming I'm the administrator of the machine, how can I pull off this trick in the context of console-kit? If it's even possible, it sounds like I'd have to suspend the existing pulseaudio connection by assigning rights to a virtual console of some kind, which would then have the opportunity to use the audio device until it released it. If you are root you can do anything you want, including doing the baddest things to your audio devices you want. And as mentioned a gazillion of times in recetn distros even non-root users can do this, regardless whether they are logged in or not, if they are a member of the audio group. Incidentally, this seems to be the same use case that vision-impaired users were dealing with recently: How can system-level processes inject their inputs to the speakers without a system-level pulseaudio daemon sharing that hardware? Nope, there should not be a system-level process generating the speech audio. It should be a user/session process. Now, unfortunately the current solutions are mostly based on system daemons, but that doesn't mean that that would be the correct way to handle these things. Because it is not. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, Feb 17, 2010 at 12:25:27PM EST, Lennart Poettering wrote: On Wed, 10.02.10 18:49, Jeremy Nickurak (pulseaudio-disc...@trk.nickurak.ca) wrote: Incidentally, this seems to be the same use case that vision-impaired users were dealing with recently: How can system-level processes inject their inputs to the speakers without a system-level pulseaudio daemon sharing that hardware? Nope, there should not be a system-level process generating the speech audio. It should be a user/session process. Now, unfortunately the current solutions are mostly based on system daemons, but that doesn't mean that that would be the correct way to handle these things. Because it is not. There are a group of us gradually moving everything a11y, including speech output/audio into user sessions, and as discussed last month, an idle like user that consolekit/udev knows about is needed for those speech/audio processes that users want to use so they can get a text console login screen to be usable. Should nobody else get to this in the coming months, this is on my agenda. Luke ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Thu, 11.02.10 02:01, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Jeremy Nickurak at 11/02/10 01:48 did gyre and gimble: A question about the console-kit approach, where the user physically near the sound hardware is the person that gets to use it... A favorite trick of mine is to ssh into a machine, and use the sound hardware there to announce some kind of event. It might be an alarm to wake up a family member, or a remotely-generated event alert. It might not be SSH, it might be a cron job, or a CGI... Assuming I'm the administrator of the machine, how can I pull off this trick in the context of console-kit? If it's even possible, it sounds like I'd have to suspend the existing pulseaudio connection by assigning rights to a virtual console of some kind, which would then have the opportunity to use the audio device until it released it. If you're an admin you'd simply su to the active user and use their access credentials to access their PA system. Also, one could make your admin user member of the audio group, and access the audio device regardless of who's logged in -- but potentially you'll clash with a running PA/audio app which already has the device open. Or, at a higher level you could configure /etc/pulse/default.pa's module-native-protocol-unix to use an auth-group even when running in per-session-mode. All user session should then pick that up and members of that group will always be allowed access. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
2010/2/11 Lennart Poettering lenn...@poettering.net: On Wed, 10.02.10 10:45, Maarten Bosmans (mkbosm...@gmail.com) wrote: The other mode is the system-wide daemon mode. This follows more the traditional unix model of a dedicated pulse user running a daemon to which other users can connect. The system mode is more applicable to an audio server/appliance scenario. I would actually argue that the normal per-session PA logic is much more unixish than anything else. At least on my classic TTYs the bell sound was actually generated in the terminal computer and not on the server computer. And on the old standalone X terminals, it's the very same thing. XBell() is called on the terminal server, and the X terminal generates the sound. That makes sense for the bell. I was referring to the daemon though. In my view the system wide daemon running as a dedicated user (apache, postgres) is an example of the traditional unix model and the per-user daemon (dbus, pulse) is another approach that is gaining a lot of popularity lately on linux distributions. Maarten So, what was true for teletype and X terminals back in the 80s, where the beep sound was played by an app on the terminal server and generated on the terminal client, is still true in the PA world: the audio stream a music player app plays on the terminal server is played back on the terminal client. So, once and for all, if someone complains that PA wasn't unixish enough: first of all, I don't care, and secondly that's a completely bogus statement and is not true. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
I did that originally. The problem is that I'm building Vinux ISOs on Ubuntu using remastersys, and I'd have to modify ubiquity to change the default user groups. The result is that after isntalling Vinux, Orca doesn't come up talking. Now, I may go modify ubiquity, but I'm more familiar now with PA than ubiquity, and I took a shortcut. Long-term, I'll probably figure out how to change ubiquity to change default user groups. However, since all real users and root will be in the pulse-access group by default, it wont add much in the way of security. Bill On Wed, Feb 10, 2010 at 5:30 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 07.02.10 22:54, Bill Cox (waywardg...@gmail.com) wrote: Finally, disable group-based authentication to use the sound system. Edit /etc/pulse/system.pa. Find the line that reads: load-module module-native-protocol-unix and change it to read: load-module module-native-protocol-unix auth-anonymous=1 It's much easier and safer to simply add all users to the pulse-access group instead of doing dirty security hacks like this. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Lennart Poettering wrote: On Tue, 09.02.10 22:52, David Henningsson (launchpad@epost.diwic.se) wrote: There are just too many people for where the ordinary PA setup (all soundcards are of exclusive use to the person logged into the current X session) is not acceptable, and worse, it isn't easy for them to either reconfigure PA, or replace PA, with something that suits their needs. I doubt the too many. Let's conclude that our milages vary, then. The handful of people coming up with this from time to time is fairly minimal, I you allow me to say so. Oh. Most of the people don't complain here. They go googling and find solutions such as stacking PA on top of dmix, using alsa-plughw directly from an application, remove all traces of PA from the system, etc etc, with various degree of success. Sometimes the information is meant for another distro or version, and they end up messing up more than they fix. Anyway, reading this thread has been helpful and I got a few pointers. I'll see if I can sum it up in one page to make the information more accessible. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Lennart Poettering wrote: On Wed, 10.02.10 07:14, David Henningsson (launchpad@epost.diwic.se) wrote: But printers are more of a system-wide resource, and for some use cases, so is the soundcard. This is nonsense. I am not sure how your ears are constructed, but on a multiseat system if you want to share a soundcard between two seats, where would you put the speakers so that the two users have the same distance from L and R and they are on the left and the right side? I mean, those users would have to sit on top of each other or detachable ears or something. Detachable ears seems cool, although I'd prefer headphones. Anyway, multiseat wasn't the use case I was talking about here, I was more thinking of the use computer as combined desktop workstation and independent media player for the kitchen use case. We discussed this with a couple of folks long time ago, and decided that some reasources are per-seat resources, and should be configured like that. Those devices are keyboards, mice, screens, sound cards, webcams and a couple of others. the UDEV_ACL=1 property in the udev tree marks most of them. This discussion was mostly done on the udev level btw, it is only indirectly related to PA. Now, in some non-standard cases it might make sense to have the access rules deviate from this default, but those are the exceptions, not the common cases. And that means that you configure it that way, but the default will be the safe, common case, not the dangerous uncommon case. Exactly. BTW, I really do not know why I am even responding, Neither do I. If I knew what makes you respond to some posts and leave others behind, I would have used that knowledge to make you respond to the alsa-plugins patch I suggested earlier [1]. Do you know this Google thing? It's kinda cool, you should try it. Never heard of it. I'll go search for it and see if I find something. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? Right, allow every user to listen into all voip calls, You're mixing the use cases up. The soundcards you use to make voip calls, are not necessarily the ones you want to share with other users. Lemme guess, you disable access control to your X11 screen too? There are use cases for that as well, but we can leave them out for now. // David [1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-February/006471.html ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and David Henningsson at 10/02/10 06:14 did gyre and gimble: Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio For user Foo, the sound card sounds like it's dedicated for Foo. If this is the case the a udev rule should be written to ensure that only Foo has ACL rights on this file and any console-kit udev-acl callouts are ignored. That makes sense, thanks. I added that reply to the blueprint. For user Bar, I feel this is invalid. Why should user Bar have the right to output a sound any more than he has the right to display a popup window on my desktop? Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? It's a fair enough point, but I don't think that sound and printers are so alike. Even the scanner example AFAIK would fall under the current PA setup - I believe that sane accesses them on a per-user basis with appropriate ACLs on the device.. /me checks [co...@jimmy ~]$ su test Password: [t...@jimmy colin]$ scanimage -L libusb couldn't open USB device /dev/bus/usb/005/011: Permission denied. libusb requires write access to USB device nodes. No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). [t...@jimmy colin]$ exit [co...@jimmy ~]$ scanimage -L device `plustek:libusb:005:011' is a Canon CanoScan LiDE25 flatbed scanner So yes, scanning is the same as sound right now. That's how ConsoleKit works. Printing is handled by cups and user access rights are handled therein. So there is nothing specifically wrong with the approach taken by cups, but by the same token, if every single subsystem implemented it's own system wide daemon and user authentication system we'd have a hell of a mess. As printing is quite often a network resource, then some kind of public facing daemon makes sense here. Standardising on the use of ConsoleKit makes a lot of sense. As for multi-seat, this is already in hand. Console-Kit has support for multi-seat stuff (tho' it may not be complete - I'm not overly sure here). What may still remain to be done is to tag certain devices as being for particular seats so that console-kit/udev can apply the appropriate ACLs when the set becomes active for a given user. All the multi-seat stuff is below PA tho' We'll just honour what it tells us. I don't think we don't need to add specific support for it. And the way ck/udev tells PA what devices it can use, is through device permissions? Yeah, if we have permission on the device, we use it, otherwise it's ignored. When users are switched away, CK fires off dbus signals and we recheck our device access etc. We don't accept any input from alsa when we do not have permission on the device (even tho' we can read mixer settings). If we were able to access the device when we were started but subsequently have our permission removed, this is indicative of user switching (i.e. Show Login Window or Switch User or Log in as a Different User) in which case we cork any streams tied to those devices we can no longer access until such times as they become available to us again. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, Feb 10, 2010 at 9:54 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and David Henningsson at 10/02/10 06:14 did gyre and gimble: Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio For user Foo, the sound card sounds like it's dedicated for Foo. If this is the case the a udev rule should be written to ensure that only Foo has ACL rights on this file and any console-kit udev-acl callouts are ignored. That makes sense, thanks. I added that reply to the blueprint. For user Bar, I feel this is invalid. Why should user Bar have the right to output a sound any more than he has the right to display a popup window on my desktop? Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? It's a fair enough point, but I don't think that sound and printers are so alike. Even the scanner example AFAIK would fall under the current PA setup - I believe that sane accesses them on a per-user basis with appropriate ACLs on the device.. /me checks [co...@jimmy ~]$ su test Password: [t...@jimmy colin]$ scanimage -L libusb couldn't open USB device /dev/bus/usb/005/011: Permission denied. libusb requires write access to USB device nodes. this is another wrong assumption, libusb uses raw USB access, if every user would have access to USB some devices might be damaged. Sane would need to be serverbased, full raw access to the usb bus would seriously be a security risk (imagine RAW USB access to a USB harddisk). Best Regards, Markus No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). [t...@jimmy colin]$ exit [co...@jimmy ~]$ scanimage -L device `plustek:libusb:005:011' is a Canon CanoScan LiDE25 flatbed scanner So yes, scanning is the same as sound right now. That's how ConsoleKit works. Printing is handled by cups and user access rights are handled therein. So there is nothing specifically wrong with the approach taken by cups, but by the same token, if every single subsystem implemented it's own system wide daemon and user authentication system we'd have a hell of a mess. As printing is quite often a network resource, then some kind of public facing daemon makes sense here. Standardising on the use of ConsoleKit makes a lot of sense. As for multi-seat, this is already in hand. Console-Kit has support for multi-seat stuff (tho' it may not be complete - I'm not overly sure here). What may still remain to be done is to tag certain devices as being for particular seats so that console-kit/udev can apply the appropriate ACLs when the set becomes active for a given user. All the multi-seat stuff is below PA tho' We'll just honour what it tells us. I don't think we don't need to add specific support for it. And the way ck/udev tells PA what devices it can use, is through device permissions? Yeah, if we have permission on the device, we use it, otherwise it's ignored. When users are switched away, CK fires off dbus signals and we recheck our device access etc. We don't accept any input from alsa when we do not have permission on the device (even tho' we can read mixer settings). If we were able to access the device when we were started but subsequently have our permission removed, this is indicative of user switching (i.e. Show Login Window or Switch User or Log in as a Different User) in which case we cork any streams tied to those devices we can no longer access until such times as they become available to us again. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 10/02/10 06:51 did gyre and gimble: Also imagine TV tuners, webcams are basically handled the same way. One user might want to capture a TV movie, while the other one doesn't need access to it. The user may want to do that but it doesn't mean that they should. I mean seriously, how many users really want to do this? We're talking about network use here - multiseat stuff and user switching works fine so we're specifically saying that someone wants to SSH in and take control of the webcam. For tv tuners there is typically a middleware involed - e.g. mythbackend or vdr etc. so doesn't really apply. The ck assignment would not be valid for this. I disagree. Now imagine we have a DVB device, multiple users can access the same TV channel. While another user might stream or capture the TV content the user sitting behind the PC might watch the current tuned in TV channel. This is a not so unlikely scenario with our devices. So use mythbackend + mythfrontend or vdr+vdr-receiver or whatever ti's called. This is also just another example where the MS-DOS like single user scenario does not fit. Dude, WTF? Seriously, stop spouting rubbish. My whole comment here has been about multi-user setups and controlled handover of permissions between users when appropriate. This is a million miles away form a single user scenario. The fact we don't agree that the system should be open up to abuse from any user who happens to have access does not make this anything like MS-DOS. If you want to be taken seriously in a discussion, keep your points valid and on topic. Here is a (horrible) suggestion. How about this: 1. Implement a Request Permission call in console-kit. 2. When an SSH user logs in, and tried to access a device, they can fire of the Request Permission API in CK. 3. A ck-agent-gui running as the active user fires up a dialog asking. User Bob is asking for permission to use Insert H/W here. This will mean you no longer have access to this device until Bob is done with it. Do you want to let him have it? That way the user who has the right to use the device can gracefully hand over that right to another user. Personally I think this is horrible, intrusive and fairly ugly and would be a whole framework designed to cater for a very niche use case and thus would ultimately be buggy and likely contain security holes. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 10/02/10 08:59 did gyre and gimble: On Wed, Feb 10, 2010 at 9:54 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? It's a fair enough point, but I don't think that sound and printers are so alike. Even the scanner example AFAIK would fall under the current PA setup - I believe that sane accesses them on a per-user basis with appropriate ACLs on the device.. /me checks [co...@jimmy ~]$ su test Password: [t...@jimmy colin]$ scanimage -L libusb couldn't open USB device /dev/bus/usb/005/011: Permission denied. libusb requires write access to USB device nodes. this is another wrong assumption, libusb uses raw USB access, if every user would have access to USB some devices might be damaged. Sane would need to be serverbased, full raw access to the usb bus would seriously be a security risk (imagine RAW USB access to a USB harddisk). I fail to see where my assumption is here. Console-Kit has applied appropriate ACLs to the device node. That was my point and it was correct. No assumption stated nor needed as to what happens further down the stack. [t...@jimmy colin]$ getfacl /dev/bus/usb/005/011 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/005/011 # owner: root # group: root user::rw- user:colin:rw- group::rw- mask::rw- other::r-- The same is true of audio devices. What if multiple users were allowed direct access. Someone may design a security system with an alarm driven from the sound system but some other user has come in and hogged the device and as it does not support hardware mixing the nuclear reactor meltdown in 5mins alarm does not sound and we all die a horrible firey death. That's worse than a HD failure :p Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
2010/2/9 olin.pulse@shivers.mail0.org: Maybe I'm wrong. I can't figure out *what* the model is, really. When I click on padevchooser's Configure Local Sound Server entry, I get a window whose Network Server tab lets me enable network access to local sound devices. Furthermore, I can set or clear a checkbox for Don't require authentication. But I can find nowhere any description of what this authentication would be. The documentation for PulseAudio is pretty weak; it mostly says that things work; just try them out. That's not documentation. Perhaps the confusion stems from the fact that PulseAudio has two different modes. The normal per-user mode, which should almost always be used, uses the model of a single user having access to the hardware of a single seat. This works great and really polishes the whole desktop experience, including support for fast user switching, remote ssh logins, etc. The other mode is the system-wide daemon mode. This follows more the traditional unix model of a dedicated pulse user running a daemon to which other users can connect. The system mode is more applicable to an audio server/appliance scenario. I have, for example, PulseAudio running as a system daemon on a dedicated server, connected to several speakers around the house. A local MPD process on the server can play music through the pulse server, or I can ssh to the box and start an internet radio stream. Moreover, sound can be redirected from any desktop to the pulse server, so that even the neighbors can enjoy the YouTube clips I'm watching. So when talking about what model PulseAudio uses, it is good to keep the distinction between per-user and system-wide mode, which have of course very different models. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Bah, wrong thread 2010/2/10 Maarten Bosmans mkbosm...@gmail.com: 2010/2/9 olin.pulse@shivers.mail0.org: Maybe I'm wrong. I can't figure out *what* the model is, really. When I click on padevchooser's Configure Local Sound Server entry, I get a window whose Network Server tab lets me enable network access to local sound devices. Furthermore, I can set or clear a checkbox for Don't require authentication. But I can find nowhere any description of what this authentication would be. The documentation for PulseAudio is pretty weak; it mostly says that things work; just try them out. That's not documentation. Perhaps the confusion stems from the fact that PulseAudio has two different modes. The normal per-user mode, which should almost always be used, uses the model of a single user having access to the hardware of a single seat. This works great and really polishes the whole desktop experience, including support for fast user switching, remote ssh logins, etc. The other mode is the system-wide daemon mode. This follows more the traditional unix model of a dedicated pulse user running a daemon to which other users can connect. The system mode is more applicable to an audio server/appliance scenario. I have, for example, PulseAudio running as a system daemon on a dedicated server, connected to several speakers around the house. A local MPD process on the server can play music through the pulse server, or I can ssh to the box and start an internet radio stream. Moreover, sound can be redirected from any desktop to the pulse server, so that even the neighbors can enjoy the YouTube clips I'm watching. So when talking about what model PulseAudio uses, it is good to keep the distinction between per-user and system-wide mode, which have of course very different models. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10 Feb 2010 10:45:33 +0100 Maarten Bosmans mkbosm...@gmail.com wrote: 2010/2/9 olin.pulse@shivers.mail0.org: Maybe I'm wrong. I can't figure out *what* the model is, really. When I click on padevchooser's Configure Local Sound Server entry, I get a window whose Network Server tab lets me enable network access to local sound devices. Furthermore, I can set or clear a checkbox for Don't require authentication. But I can find nowhere any description of what this authentication would be. The documentation for PulseAudio is pretty weak; it mostly says that things work; just try them out. That's not documentation. Perhaps the confusion stems from the fact that PulseAudio has two different modes. The normal per-user mode, which should almost always be used, uses the model of a single user having access to the hardware of a single seat. This works great and really polishes the whole desktop experience, including support for fast user switching, remote ssh logins, etc. The other mode is the system-wide daemon mode. This follows more the traditional unix model of a dedicated pulse user running a daemon to which other users can connect. The system mode is more applicable to an audio server/appliance scenario. I have, for example, PulseAudio running as a system daemon on a dedicated server, connected to several speakers around the house. A local MPD process on the server can play music through the pulse server, or I can ssh to the box and start an internet radio stream. Moreover, sound can be redirected from any desktop to the pulse server, so that even the neighbors can enjoy the YouTube clips I'm watching. I have basically the same setup - would you mind sharing your config files with me? Preferably of both, the server, and of your clients, that is e.g. the computer you watch the youtube clips on, that your neighbors enjoy... So when talking about what model PulseAudio uses, it is good to keep the distinction between per-user and system-wide mode, which have of course very different models. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss Thank you very much. -- samuel sam...@eightonions.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Here's what I don't understand. Why doesn't PA run in system-wide mode, but still do all the same user-permission checks it does now, and only authorize the current user to access the sound card? Is there any advantage in running the whole PA daemon in user space? Why have multiple PA processes running when there are multiple users? Doesn't this waste memory? If PA were run this way, it would be trivial to allow specific root processes or authorized users to access the sound card at the same time as the current user. Also, why does zero latency by default increase CPU power? SFAIK, zero latency (or inperceptably small) is the default in all other sound systems, and I haven't heard of increased CPU usage as a result. Thanks, Bill On Wed, Feb 10, 2010 at 4:13 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 10/02/10 08:59 did gyre and gimble: On Wed, Feb 10, 2010 at 9:54 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? It's a fair enough point, but I don't think that sound and printers are so alike. Even the scanner example AFAIK would fall under the current PA setup - I believe that sane accesses them on a per-user basis with appropriate ACLs on the device.. /me checks [co...@jimmy ~]$ su test Password: [t...@jimmy colin]$ scanimage -L libusb couldn't open USB device /dev/bus/usb/005/011: Permission denied. libusb requires write access to USB device nodes. this is another wrong assumption, libusb uses raw USB access, if every user would have access to USB some devices might be damaged. Sane would need to be serverbased, full raw access to the usb bus would seriously be a security risk (imagine RAW USB access to a USB harddisk). I fail to see where my assumption is here. Console-Kit has applied appropriate ACLs to the device node. That was my point and it was correct. No assumption stated nor needed as to what happens further down the stack. [t...@jimmy colin]$ getfacl /dev/bus/usb/005/011 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/005/011 # owner: root # group: root user::rw- user:colin:rw- group::rw- mask::rw- other::r-- The same is true of audio devices. What if multiple users were allowed direct access. Someone may design a security system with an alarm driven from the sound system but some other user has come in and hogged the device and as it does not support hardware mixing the nuclear reactor meltdown in 5mins alarm does not sound and we all die a horrible firey death. That's worse than a HD failure :p Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Bill Cox at 10/02/10 10:50 did gyre and gimble: Here's what I don't understand. Why doesn't PA run in system-wide mode, but still do all the same user-permission checks it does now, and only authorize the current user to access the sound card? Is there any advantage in running the whole PA daemon in user space? Why have multiple PA processes running when there are multiple users? Doesn't this waste memory? If PA were run this way, it would be trivial to allow specific root processes or authorized users to access the sound card at the same time as the current user. Yes the system-wide approach works fine for this, but it still doesn't address several issues. One is the fact that why should a module be loaded into a system-wide component for a specific user? e.g. user A pairs his bluetooth headset which will require that the bluetooth sink becomes available - this should only be for user A, no other users, but user A is somehow allowed to load a module into the system service for this to happen. Users loading modules into a system service is generally a security concern (which is my most system wide daemons disallow module loading). Lots of things about the sound stack are per-user (e.g. my Apple Airtunes, my Bluetooth devices etc. etc.) and pushing these into a system service does not make sense. It is possible that a system wide component could drive the local hardware and a per-user component is able to deal with all the other stuff, per-user settings and devices etc. but also communicate with the server side componenet to deal with local physical hardware. This approach is much more complex and would no doubt introduce a lot of potential problems regarding SHM security and such like but it should all be possible. That said I'm not convinced there is a compelling enough use case to go down this route anyway as I've pointed out. Also there is always going to be the argument that X is a system device in one context and a per-user device in another. e.g. this apply airtunes is in my room so it's mine, but this one is in the kitchen so it's everyone's. No matter what approach you take there are always going to be some people who want it to work another way. We've got to concentrate on the majority use cases and so fare the only awkward ones pointed out are very niche and really are getting far too much discussion time already considering the overall goal. Also, why does zero latency by default increase CPU power? SFAIK, zero latency (or inperceptably small) is the default in all other sound systems, and I haven't heard of increased CPU usage as a result. http://0pointer.de/blog/projects/pulse-glitch-free.html In an ideal world you want a latency of about 2-10 seconds depending on context of the running application (e.g. a music player where you don't rewind/fast-forward too much and do not mix audio over the top too often should have a very high latency to allow the CPU to sleep as much as possible rather than wake up to service audio data. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Ok, the new glitchless code sounds cool. Reducing the interrupts seems close to pointless from a power savings view, unless we're in an embedded environment where we slow down the CPU and lower it's power on sub-second intervals. Otherwise, copying the data the data to the sound buffer will heavily dominate power. I like that in theory, it provides zero latency (quotes theirs). In practice, for speech-dispatcher, it's good enough. I'll take a closer look next time someone complains about an old game with too much latency. As for concerns about running system-wide... Ubuntu already disallows user loaded modules, and I'm not hearing a lot of complaints. When running in system-wide mode, pretty much everyone seems happy. The complaints I'm hearing are the usual ones... how do I get my second USB sound card working and such. However, when run in user-mode, I hear all sorts of bug complaints. For example, speech-dispatcher doesn't reliably go away when you log out fast enough for gdm's copy to get access to the sound card. The result is that today, in Ubuntu Lucid, if you log out, gdm randomly wont let gdm's copy of Orca read the login screen. Users offer work-arounds like putting 'killall speech-dispatcher' in .bash_logout. If security issues were handled by a system-wide daemon, I suspect PA could run more reliably. In addition, a system-wide rights manager could easily handle sound from root devices like speech-synthesizers, or alarms. A flaw that people will continue to complain about in PA is it's inability to deal with multi-user sound. Bill On Wed, Feb 10, 2010 at 6:32 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Bill Cox at 10/02/10 10:50 did gyre and gimble: Here's what I don't understand. Why doesn't PA run in system-wide mode, but still do all the same user-permission checks it does now, and only authorize the current user to access the sound card? Is there any advantage in running the whole PA daemon in user space? Why have multiple PA processes running when there are multiple users? Doesn't this waste memory? If PA were run this way, it would be trivial to allow specific root processes or authorized users to access the sound card at the same time as the current user. Yes the system-wide approach works fine for this, but it still doesn't address several issues. One is the fact that why should a module be loaded into a system-wide component for a specific user? e.g. user A pairs his bluetooth headset which will require that the bluetooth sink becomes available - this should only be for user A, no other users, but user A is somehow allowed to load a module into the system service for this to happen. Users loading modules into a system service is generally a security concern (which is my most system wide daemons disallow module loading). Lots of things about the sound stack are per-user (e.g. my Apple Airtunes, my Bluetooth devices etc. etc.) and pushing these into a system service does not make sense. It is possible that a system wide component could drive the local hardware and a per-user component is able to deal with all the other stuff, per-user settings and devices etc. but also communicate with the server side componenet to deal with local physical hardware. This approach is much more complex and would no doubt introduce a lot of potential problems regarding SHM security and such like but it should all be possible. That said I'm not convinced there is a compelling enough use case to go down this route anyway as I've pointed out. Also there is always going to be the argument that X is a system device in one context and a per-user device in another. e.g. this apply airtunes is in my room so it's mine, but this one is in the kitchen so it's everyone's. No matter what approach you take there are always going to be some people who want it to work another way. We've got to concentrate on the majority use cases and so fare the only awkward ones pointed out are very niche and really are getting far too much discussion time already considering the overall goal. Also, why does zero latency by default increase CPU power? SFAIK, zero latency (or inperceptably small) is the default in all other sound systems, and I haven't heard of increased CPU usage as a result. http://0pointer.de/blog/projects/pulse-glitch-free.html In an ideal world you want a latency of about 2-10 seconds depending on context of the running application (e.g. a music player where you don't rewind/fast-forward too much and do not mix audio over the top too often should have a very high latency to allow the CPU to sleep as much as possible rather than wake up to service audio data. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 2010-02-10 at 11:16 -0500, Bill Cox wrote: Ok, the new glitchless code sounds cool. Reducing the interrupts seems close to pointless from a power savings view, unless we're in an embedded environment where we slow down the CPU and lower it's power on sub-second intervals. Otherwise, copying the data the data to the sound buffer will heavily dominate power. Why would the power concerns not apply on laptops and netbooks? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Arun Raghavan at 10/02/10 19:26 did gyre and gimble: On Wed, 2010-02-10 at 11:16 -0500, Bill Cox wrote: Ok, the new glitchless code sounds cool. Reducing the interrupts seems close to pointless from a power savings view, unless we're in an embedded environment where we slow down the CPU and lower it's power on sub-second intervals. Otherwise, copying the data the data to the sound buffer will heavily dominate power. Why would the power concerns not apply on laptops and netbooks? And tablets *everyone* loves tablets these days except for all those folks who don't :p -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
The power savings on a laptop will be so close to zero, you couldn't measure the improvement in battery life. 40 interupts per second (what raw ALSA does) compared to streaming 22KB per seccond to the sound card is too small to care. You wont notice any improvement. On Wed, Feb 10, 2010 at 2:26 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Arun Raghavan at 10/02/10 19:26 did gyre and gimble: On Wed, 2010-02-10 at 11:16 -0500, Bill Cox wrote: Ok, the new glitchless code sounds cool. Reducing the interrupts seems close to pointless from a power savings view, unless we're in an embedded environment where we slow down the CPU and lower it's power on sub-second intervals. Otherwise, copying the data the data to the sound buffer will heavily dominate power. Why would the power concerns not apply on laptops and netbooks? And tablets *everyone* loves tablets these days except for all those folks who don't :p -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Sun, 07.02.10 22:54, Bill Cox (waywardg...@gmail.com) wrote: Finally, disable group-based authentication to use the sound system. Edit /etc/pulse/system.pa. Find the line that reads: load-module module-native-protocol-unix and change it to read: load-module module-native-protocol-unix auth-anonymous=1 It's much easier and safer to simply add all users to the pulse-access group instead of doing dirty security hacks like this. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 09.02.10 03:16, Markus Rechberger (mrechber...@gmail.com) wrote: On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Not true. Firstly, what we don't support is simultaneous playback on the same device by multiple different users, unless you reconfigure things. Which is the same as for traditional alsa dmix. Secondly, the system wide mode is not deprecated. It's just not recommended for use for multi-user systems. It's fine on headless devices, or on thin clients, where no local user exists. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Mon, 08.02.10 21:01, olin.pulse@shivers.mail0.org (olin.pulse@shivers.mail0.org) wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? On a headless system, or on a system where no local users exist (i.e. thin clients), use the system-wide mode. On multi-user systems, don't. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 09.02.10 09:43, Markus Rechberger (mrechber...@gmail.com) wrote: Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. Bad example as usual, on OSX everyone (who's permitted to use the audio unit) can just log in and use the audio unit. Do we need to have this pointless discussion every second months? Last time I checked OSX audio of the sessions that are not in the foreground is paused, and only one session has access to the sound cards at a time. Exactly like on PA, or on Windows. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 09.02.10 11:17, Bill Cox (waywardg...@gmail.com) wrote: The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? Tsss. This is a pretty peripheral battle field. I am quite sure that the this will not make the complainers shut up. I guess the only other really nasty e-mails I read about PA are due to old unmaintained code (typically games) that have too much delay in PA. Is there any good reason that the default latency in PA for programs that don't bother setting a desired latency is greater than zero? I think this is really not how things are. At least not from my perspective, which I think it a very informed one how I like to think. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 09.02.10 12:24, Jeremy Nickurak (jer...@nickurak.ca) wrote: On Tue, Feb 9, 2010 at 09:41, Tanu Kaskinen ta...@iki.fi wrote: That's easier said than done. Only one process can have direct access to the sound card at a time. Each user has his own pulseaudio instance running. How do you implement constant access in such scenario? I fear it would require a major redesign effort in pulseaudio. I haven't seen any concrete design proposals enabling simultaneous access for multiple users while at the same time retaining all the desirable properties that the current system has. Off the top of my head root or other system-level pulseaudio instance opens and owns the physical hardware for the entire time a computer is up. All the user pulseaudio instances connect through that. What's the downside here? You don't want to stack audio stacks (hey, a pun!), for latency, memory consumption reasons. Also, you don't want to get into this permission mess, which you will doubtlessly enter if you want to make this fast, i.e. continue to support SHM and so on. Alternatively, rely on the underlying layer to do multiplexing. If the hardware supports it, awesome. If it doesn't, let dmix handle it. Modern hw doesn't support it. And dmix doesn't do any of the timer-based scheduling stuff we want. It's not that easy. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 09.02.10 18:41, Tanu Kaskinen (ta...@iki.fi) wrote: ti, 2010-02-09 kello 11:17 -0500, Bill Cox kirjoitti: The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? That's easier said than done. Only one process can have direct access to the sound card at a time. Each user has his own pulseaudio instance running. How do you implement constant access in such scenario? I fear it would require a major redesign effort in pulseaudio. I haven't seen any concrete design proposals enabling simultaneous access for multiple users while at the same time retaining all the desirable properties that the current system has. Also, if this is all just about ways so that different users can pass audio to each other, there are simpler ways to achieve that. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 09.02.10 22:52, David Henningsson (launchpad@epost.diwic.se) wrote: Colin Guthrie wrote: 'Twas brillig, and Jeremy Nickurak at 09/02/10 19:24 did gyre and gimble: This whole thing has been discussed to death, and I really don't feel like being drawn into the whole thing again. From what I've read here, I'm afraid it's going to keep coming up until we solve it somehow. I can live with that. Asking them to try the mailing list archives or google is not a particularly difficult task. There are just too many people for where the ordinary PA setup (all soundcards are of exclusive use to the person logged into the current X session) is not acceptable, and worse, it isn't easy for them to either reconfigure PA, or replace PA, with something that suits their needs. I doubt the too many. The handful of people coming up with this from time to time is fairly minimal, I you allow me to say so. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 09.02.10 17:59, Markus Rechberger (mrechber...@gmail.com) wrote: On Tue, Feb 9, 2010 at 5:17 PM, Bill Cox waywardg...@gmail.com wrote: The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? Comparisons to MAC and Windows have been going on for a while, and the PA guys are basically right that PA is more like Windows and Mac than the older sound systems. If I'm not mistaken, the real issue is all the very valid reasons people out in Linux land have for multi-user simultaneous access to sound. I'd say those guys are generating most of the negative PA e-mails I read, and not just on this forum. you cannot compare it with mac, on mac multiuser access works like it worked with alsa and OSS. Uh. This is very a confused statement. PA opens the device when the ALSA device node access permissions allow that. That access is controlled via udev's acl tool. We open the device when we get access to the device nodes, and we close it when we lose it. The legacy OSS device node permissions follow exactly the ALSA device node permissions. Which basically means that we simply follow the ALSA/OSS permission logic. We don't open any new doors, we don't close any from the underlying system. As such the destinction between ALSA/OSS and PA regardings access control is simple not existant, your claim above is bogus. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10.02.10 07:14, David Henningsson (launchpad@epost.diwic.se) wrote: But printers are more of a system-wide resource, and for some use cases, so is the soundcard. This is nonsense. I am not sure how your ears are constructed, but on a multiseat system if you want to share a soundcard between two seats, where would you put the speakers so that the two users have the same distance from L and R and they are on the left and the right side? I mean, those users would have to sit on top of each other or detachable ears or something. We discussed this with a couple of folks long time ago, and decided that some reasources are per-seat resources, and should be configured like that. Those devices are keyboards, mice, screens, sound cards, webcams and a couple of others. the UDEV_ACL=1 property in the udev tree marks most of them. This discussion was mostly done on the udev level btw, it is only indirectly related to PA. Now, in some non-standard cases it might make sense to have the access rules deviate from this default, but those are the exceptions, not the common cases. And that means that you configure it that way, but the default will be the safe, common case, not the dangerous uncommon case. So, how do you reconfigure access to audio devices like that? More recent udev versions know an audio group. Just make yourself a member of that, and you'll have access regardless of the current console user. Or alternatively use some udev rules to patch the device access differently. BTW, I really do not know why I am even responding, this has been answered before and before. Do you know this Google thing? It's kinda cool, you should try it. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? Right, allow every user to listen into all voip calls, and to fake output. Lemme guess, you disable access control to your X11 screen too? And the way ck/udev tells PA what devices it can use, is through device permissions? PA gets the device access rights directly from the /dev tree. It doesn't query CK or udev for those. We try to keep our stacks thin. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10.02.10 05:50, Bill Cox (waywardg...@gmail.com) wrote: Here's what I don't understand. Why doesn't PA run in system-wide mode, but still do all the same user-permission checks it does now, and only authorize the current user to access the sound card? Because that is extraordinarily difficult to get right. first of all, we would have to authorize every single request, and come up with ACL logic for every single entity inside of PA. i.e. if a user issues move request we would have to check whether the user is allowed to move this particular stream and to this particular device and so on. This would add a substantial and complex codebase to PA. Also, suddenly the bigger part of PA suddenly becomes security sensitive because we can never trust the user anymore. This would also mean that we would have to get rid of stuff like SHM data transfer because I simply see no way to implement this on current linuxes in a safe way so that the two sides don't have to trust each other. (the most trivial access is that one side ftruncates its shm region triggering a SIGBUS in the other on the next access. And catching those SIGBUS and handling it sanely and securely you cannot really do. but that's just the beginning, it goes downhill from there.) I mean, you are welcome to write such a franken-sound-server, which can deal with all of this. But I simply don't think it is feasible. I won't wast my time on that and reimplement big parts of the linux kernel in userspace. Certainly not just because some people want to playback audio simultaneously from multiple users and cannot configure module-native-protocol-xxx/module-tunnel-sink for that. Is there any advantage in running the whole PA daemon in user space? Why have multiple PA processes running when there are multiple users? Doesn't this waste memory? Next question: why have multiple firefox processes running? doesn't that waste memory? I mean, multiple users could share one instance, right? /sarcasm If PA were run this way, it would be trivial to allow specific root processes or authorized users to access the sound card at the same time as the current user. trivial. Right. Also, why does zero latency by default increase CPU power? SFAIK, zero latency (or inperceptably small) is the default in all other sound systems, and I haven't heard of increased CPU usage as a result. zero latency does not literally mean what you apparently think it does. It simply means that you can override the very sample that is currently passed to the DAC, it does not mean you really get 0 latency when streaming a continuous stream. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10.02.10 11:32, Colin Guthrie (gm...@colin.guthr.ie) wrote: One is the fact that why should a module be loaded into a system-wide component for a specific user? e.g. user A pairs his bluetooth headset which will require that the bluetooth sink becomes available - this should only be for user A, no other users, but user A is somehow allowed to load a module into the system service for this to happen. Users loading modules into a system service is generally a security concern (which is my most system wide daemons disallow module loading). Also note that the auth credentials (i.e. PINs) for the bt stuff would have to be passed to the server, but should be kept private for the user. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10.02.10 14:51, Bill Cox (waywardg...@gmail.com) wrote: The power savings on a laptop will be so close to zero, you couldn't measure the improvement in battery life. 40 interupts per second (what raw ALSA does) compared to streaming 22KB per seccond to the sound card is too small to care. You wont notice any improvement. Man, please make sure to inform Intel about that, so that they stop designing their systems for this logic. And Microsoft and Apple too, so that they can drop the whole logic again from Windows and MacOS. I mean, how dumb from them, that they couldn't see what is so obvious to you! It's not that we came up with the tsched idea. Didn't you know? In Free Software we don't innovate, we just reimplement other people's ideas, but better. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Mon, 08.02.10 19:11, olin.pulse@shivers.mail0.org (olin.pulse@shivers.mail0.org) wrote: PA is a system that manages access to a hardware resource, in a network distributed context. Such a system must have mechanism for managing authentication and privileges -- one that works in a network distributed context. X11 is in a very similar position -- except that there's less call for shared access to the resources it manages (in the sense that, with X11, multiple humans usually don't want access to the same screen, keyboard or mouse at the same time). X uses ~/.Xauthority, but, these days, it mostly lifts this base mechanism up to a distributed setting by means of ssh. OK, so that's X11. I cannot figure out what PA's mechanism for this is. By default we store the access creds of the PA server in the root window of the X server. Which means that everyone who has access to the X server has access to the matching PA server, too. So we mostly follow the X logic, with one exception: we only have one PA instance running per user and machine, and share it between all sessions of the same user, so that every session of the same user has access to all local cards that belong to any of the X screens. I sort of get the sense, from this per-user-login server model that PA has the horrible one-persone/one-computer model of the person at the console is the person using the computer, which was inflicted on the world by Microsoft Windows. If so, this is a real design error, one that doesn't sync up with Unix, which has always had a multi-user model of the world. Right. horrible. I mean, what you say is utterly bogus, but I don't even want to dicuss that here. I'd just like to refer you to the CK work that has been done, because that is where this logic stems from. The logic is certainly nothing we PA folks came up with. It's something CK was designed for. So please complain not to me. I certainly believe CK is what we want, but I am not its maintainer. Also, last time I checked Unix was a pretty broken system. Might be better than many, but Unix is certainly not user friendly, and a system from the 70s. We try to build a modern OS here, and that means we use what is good and innovate where it isn't. That's why people have come up with CK and it got adopted by the various distributions. If you believe that traditional Unix is the holy grail, then maybe modern Linux systems are not the right choice for you. If you however are interested in a modern multi-user/multi-seat system which inherits the good stuff from Unix, then you're welcome. Maybe I'm wrong. I can't figure out *what* the model is, really. When I click on padevchooser's Configure Local Sound Server entry, I get a window whose Network Server tab lets me enable network access to local sound devices. Furthermore, I can set or clear a checkbox for Don't require authentication. But I can find nowhere any description of what this authentication would be. The documentation for PulseAudio is pretty weak; it mostly says that things work; just try them out. That's not documentation. Checked the FAQ? Sure, the PA docs are not perfect and not complete, but they are certainly better than for many projects and you are always welcome to contribute here. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10.02.10 10:45, Maarten Bosmans (mkbosm...@gmail.com) wrote: The other mode is the system-wide daemon mode. This follows more the traditional unix model of a dedicated pulse user running a daemon to which other users can connect. The system mode is more applicable to an audio server/appliance scenario. I would actually argue that the normal per-session PA logic is much more unixish than anything else. At least on my classic TTYs the bell sound was actually generated in the terminal computer and not on the server computer. And on the old standalone X terminals, it's the very same thing. XBell() is called on the terminal server, and the X terminal generates the sound. So, what was true for teletype and X terminals back in the 80s, where the beep sound was played by an app on the terminal server and generated on the terminal client, is still true in the PA world: the audio stream a music player app plays on the terminal server is played back on the terminal client. So, once and for all, if someone complains that PA wasn't unixish enough: first of all, I don't care, and secondly that's a completely bogus statement and is not true. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Thu, Feb 11, 2010 at 12:16:44AM +0100, Lennart Poettering wrote: This is nonsense. I am not sure how your ears are constructed, but on a multiseat system if you want to share a soundcard between two seats, where would you put the speakers so that the two users have the same distance from L and R and they are on the left and the right side? I mean, those users would have to sit on top of each other or detachable ears or something. Detachable ears are called headphones. :) I'm not arguing that it's practical to do, but an ideal multiseat system would be able to give each user two dedicated channels, so they can each plug in their own set of headphones (modern surround sound cards have tons of audio outputs). Of course, implementing and configuring this would probably be extremely difficult, so I'm not volunteering. :) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Dnia 2010-02-10, śro o godzinie 16:45 -0700, Andrew McNabb pisze: I'm not arguing that it's practical to do, but an ideal multiseat system would be able to give each user two dedicated channels, so they can each plug in their own set of headphones (modern surround sound cards have tons of audio outputs). Of course, implementing and configuring this would probably be extremely difficult, so I'm not volunteering. :) Well, IIUC that's exactly what PA does - multi-seat does not mean two seats and one screen/keyboard/mouse/speakers - it means this set for every user in every seat. And that's what PA does. -- Pozdrawiam Michał (Saviq) Sawicz signature.asc Description: To jest część wiadomości podpisana cyfrowo ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 09.02.10 18:51, Colin Guthrie (gm...@colin.guthr.ie) wrote: By the way normally only the users who are in the audio group are allowed to access audio (not entirely sure how this is handled with osx though), so it's not like a random user is allowed to access the audio device. The audio group is a legacy and is no longer needed. ACLs on the audio device are far more flexible. It's actually not legacy. In fact it was known on Debian for a long time and only recently added to the other distros, too, pushed in via udev. If people want to allow users unconditional access to audio devices, regardless whether they are logged in on the console, then they can add them to that group. That's fine. ACL certainly are more flexible, but just adding someone to the audio group is certainly simpler. Most distros support both CK/ACL-based access and audio group based access out-of-the-box. And that's fine that way and not going to go away. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 09.02.10 20:07, Markus Rechberger (mrechber...@gmail.com) wrote: Bypassing this layer and accessing things directly is not IMO a good design. Everything is possible with the appropriate mechanisms in place and no functionality is sacrificed, but you have to be prepared to accept that old approaches will not last forever nor survive the tests of time. your scenario is definitely over engineered for many people out there. I see your points and I see it as a valid scenario but as mentioned not as a valid reason for hard restricting users. On the other side the only way out of this dilemma is to set up systemwide service which pretty much cannot be done in a generic way with all distributions which use PA due random config paths and inherited configuration files. As long as this isn't fixed I hope operating systems don't make a hard dependency on PA only so people can still jump back to the old behavior. It's not particularly hard to load another module-native-protocol-unix instance and losen its access restrictions to allow other users access, if you don't care about security. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Thu, 2010-02-11 at 01:46 +0100, Lennart Poettering wrote: On Tue, 09.02.10 21:57, Michał Sawicz (mic...@sawicz.net) wrote: 4. there's a dialog on the active user's session with 'User tries to access your audio equipment with application , allow / deny?' For every event sound? Really? Lennart I believe what was being referred to is a permissions-based system. Sort of like on windows, the Do you want to allow machine OMGCOOLPICS to have access to your C:\ drive? after which it saves your answer for future sounds/streams. You've already covered previously why this sort of permissions aren't PA's job though. I must say this discussion is pretty interesting, even though the substance has been the same every few months. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10.02.10 16:45, Andrew McNabb (amcn...@mcnabbs.org) wrote: Detachable ears are called headphones. :) I'm not arguing that it's practical to do, but an ideal multiseat system would be able to give each user two dedicated channels, so they can each plug in their own set of headphones (modern surround sound cards have tons of audio outputs). Of course, implementing and configuring this would probably be extremely difficult, so I'm not volunteering. :) You would call that ideal? Strange definition of ideal. It's certainly much easiert to just buy seperate super-cheap stereo USB sound cards for each user. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Thu, 11.02.10 00:44, Colin Guthrie (gm...@colin.guthr.ie) wrote: If people want to allow users unconditional access to audio devices, regardless whether they are logged in on the console, then they can add them to that group. That's fine. ACL certainly are more flexible, but just adding someone to the audio group is certainly simpler. Most distros support both CK/ACL-based access and audio group based access out-of-the-box. And that's fine that way and not going to go away. But if a good proportion of the audio hardware out there does not support hardware mixing, should this mode of operation be encouraged? I'd have thought that by enabling this way of working it's just ultimately going to lead to problems when such hardware is attempted to be accessed concurrently? The audio group is certainly no fix for apps fighting for exclusive device access. Note that by default that group is empty, so this feature is unused by default. However we want to make things easy for the cases where access control is not exclusively bound to the active session. And it might even make sense for headless systems, or if PA isn't used. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10.02.10 23:22, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Lennart Poettering at 10/02/10 22:36 did gyre and gimble: On Tue, 09.02.10 09:43, Markus Rechberger (mrechber...@gmail.com) wrote: Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. Bad example as usual, on OSX everyone (who's permitted to use the audio unit) can just log in and use the audio unit. Do we need to have this pointless discussion every second months? Last time I checked OSX audio of the sessions that are not in the foreground is paused, and only one session has access to the sound cards at a time. Exactly like on PA, or on Windows. This is correct. There is one difference tho' on OSX (which is IMO horrible) and that is the fact that an inactive user can ssh in and play sound (via e.g. afplay command line app). I annoyed the hell out of someone in my office today by doing just this. But from a user-facing perspective - e.g. logged in user they using fast user switching - it behaves exactly as you described. What I didn't try was issuing a sleep 10s; afplay foo.mp3 and initiating the switch. I'll try that tomorrow. So you can even monitor everything he says via the mike? If so, could you please provide a live stream on the internet please? ;-) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 2010-02-10 at 16:52 -0800, Lennart Poettering wrote: On Wed, 10.02.10 16:45, Andrew McNabb (amcn...@mcnabbs.org) wrote: Detachable ears are called headphones. :) I'm not arguing that it's practical to do, but an ideal multiseat system would be able to give each user two dedicated channels, so they can each plug in their own set of headphones (modern surround sound cards have tons of audio outputs). Of course, implementing and configuring this would probably be extremely difficult, so I'm not volunteering. :) You would call that ideal? Strange definition of ideal. It's certainly much easiert to just buy seperate super-cheap stereo USB sound cards for each user. That, greatly depends on what your companies procurement process looks like. ;) Kevin Lennart ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
A question about the console-kit approach, where the user physically near the sound hardware is the person that gets to use it... A favorite trick of mine is to ssh into a machine, and use the sound hardware there to announce some kind of event. It might be an alarm to wake up a family member, or a remotely-generated event alert. It might not be SSH, it might be a cron job, or a CGI... Assuming I'm the administrator of the machine, how can I pull off this trick in the context of console-kit? If it's even possible, it sounds like I'd have to suspend the existing pulseaudio connection by assigning rights to a virtual console of some kind, which would then have the opportunity to use the audio device until it released it. Incidentally, this seems to be the same use case that vision-impaired users were dealing with recently: How can system-level processes inject their inputs to the speakers without a system-level pulseaudio daemon sharing that hardware? -- Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =- ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
A question about the console-kit approach, where the user physically near the sound hardware is the person that gets to use it... A favorite trick of mine is to ssh into a machine, and use the sound hardware there to announce some kind of event. It might be an alarm to wake up a family member, or a remotely-generated event alert. It might not be SSH, it might be a cron job, or a CGI... Assuming I'm the administrator of the machine, how can I pull off this trick in the context of console-kit? If it's even possible, it sounds like I'd have to suspend the existing pulseaudio connection by assigning rights to a virtual console of some kind, which would then have the opportunity to use the audio device until it released it. Incidentally, this seems to be the same use case that vision-impaired users were dealing with recently: How can system-level processes inject their inputs to the speakers without a system-level pulseaudio daemon sharing that hardware? -- Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =- ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Jeremy Nickurak at 11/02/10 01:48 did gyre and gimble: A question about the console-kit approach, where the user physically near the sound hardware is the person that gets to use it... A favorite trick of mine is to ssh into a machine, and use the sound hardware there to announce some kind of event. It might be an alarm to wake up a family member, or a remotely-generated event alert. It might not be SSH, it might be a cron job, or a CGI... Assuming I'm the administrator of the machine, how can I pull off this trick in the context of console-kit? If it's even possible, it sounds like I'd have to suspend the existing pulseaudio connection by assigning rights to a virtual console of some kind, which would then have the opportunity to use the audio device until it released it. If you're an admin you'd simply su to the active user and use their access credentials to access their PA system. Incidentally, this seems to be the same use case that vision-impaired users were dealing with recently: How can system-level processes inject their inputs to the speakers without a system-level pulseaudio daemon sharing that hardware? They can't and they shouldn't. The problem is that the models are broken. All the models for this have been decided upon and it's just waiting for people to do the implementation in the various bits of the stack. See the archives for more info. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Thu, Feb 11, 2010 at 1:00 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 08.02.10 19:11, olin.pulse@shivers.mail0.org (olin.pulse@shivers.mail0.org) wrote: PA is a system that manages access to a hardware resource, in a network distributed context. Such a system must have mechanism for managing authentication and privileges -- one that works in a network distributed context. X11 is in a very similar position -- except that there's less call for shared access to the resources it manages (in the sense that, with X11, multiple humans usually don't want access to the same screen, keyboard or mouse at the same time). X uses ~/.Xauthority, but, these days, it mostly lifts this base mechanism up to a distributed setting by means of ssh. OK, so that's X11. I cannot figure out what PA's mechanism for this is. By default we store the access creds of the PA server in the root window of the X server. Which means that everyone who has access to the X server has access to the matching PA server, too. So we mostly follow the X logic, with one exception: we only have one PA instance running per user and machine, and share it between all sessions of the same user, so that every session of the same user has access to all local cards that belong to any of the X screens. I sort of get the sense, from this per-user-login server model that PA has the horrible one-persone/one-computer model of the person at the console is the person using the computer, which was inflicted on the world by Microsoft Windows. If so, this is a real design error, one that doesn't sync up with Unix, which has always had a multi-user model of the world. Right. horrible. I mean, what you say is utterly bogus, but I don't even want to dicuss that here. I'd just like to refer you to the CK work that has been done, because that is where this logic stems from. The logic is certainly nothing we PA folks came up with. It's something CK was designed for. So please complain not to me. I certainly believe CK is what we want, but I am not its maintainer. it does not mean that CK is the absolute right solution for everyone I second that the current default setup is not good for many users. It does not help to force people to a logic which they do not accept. I know that you see many things to be broken but many people lived with it very good for more than at least 10 years, until you came up with the first unstable PA hacks which you tried to fix it over the years (good attitude). I do agree with the other users, I do see that there is a scenario where your design is okay but it's not the ultimate solution for it, you can work as hard as you can to convince people but it will not work out. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble: On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. That is the *right* way and the default way. If you want something different then you can but you'll have to get your hands a little dirty. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 9, 2010 at 9:38 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble: On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. Bad example as usual, on OSX everyone (who's permitted to use the audio unit) can just log in and use the audio unit. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
I think this is one area where PulseAudio could be improved, though I can't quite figure out how! Surely, there must be some way to allow specific processes or users to have full sound access, while otherwise sticking to the one-user-at-a-time model. I'm trying to port SBL (another console screen reader) to Ubuntu, now, and so I've got yet another piece of code that will need substantial changes to work with the one-user-at-a-time model, in addition to speechd-up, espeakup, and speech-dispatcher. Grr... Can't we just add the concept of an allowed user, who gets to play sound no matter who's logged in? Bill On Tue, Feb 9, 2010 at 3:43 AM, Markus Rechberger mrechber...@gmail.com wrote: On Tue, Feb 9, 2010 at 9:38 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble: On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. Bad example as usual, on OSX everyone (who's permitted to use the audio unit) can just log in and use the audio unit. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 08:43 did gyre and gimble: On Tue, Feb 9, 2010 at 9:38 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble: On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. Bad example as usual, on OSX everyone (who's permitted to use the audio unit) can just log in and use the audio unit. Can you demonstrate this? In the past when I've tested this behaviour on OSX (it was quite a while ago) it behaves exactly as I described above, and I've literally just now re-tested this on a colleagues Mac (latest version): 1. Enable Fast User Switching (System Settings - Accounts - Login Options). 2. Login as user. 3. Fast user switch (top right, next to clock) to a different user. 4. With new user download and run e.g. VLC or iTunes. 5. Start playing some tunes. 6. Fast user switch back to your original user. 7. Note the blissful silence. 8. Do whatever you like with the original user login. Play tunes, check mail etc. 9. Switch back to the user who *was* playing. 10. If you used iTunes, it will now be in the Pause state so will be quiet. If you used VLC the music will continue playing now the user is active again. I guess the reason there is a difference between iTunes and VLC is that iTunes presumably listens to the cork notifications from CoreAudio and issues an application level pause, whereas VLC does not and thus is forcibly corked, but will automatically play again. This is *exactly* the same behaviour as we promote in PulseAudio too. If you can show me something that proves the above invalid, I'm all ears, but I'm pretty confident that what I said originally is correct and the above test seems to support that. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Can you demonstrate this? In the past when I've tested this behaviour on OSX (it was quite a while ago) it behaves exactly as I described above, and I've literally just now re-tested this on a colleagues Mac (latest version): 1. Enable Fast User Switching (System Settings - Accounts - Login Options). 2. Login as user. 3. Fast user switch (top right, next to clock) to a different user. 4. With new user download and run e.g. VLC or iTunes. 5. Start playing some tunes. 6. Fast user switch back to your original user. 7. Note the blissful silence. 8. Do whatever you like with the original user login. Play tunes, check mail etc. 9. Switch back to the user who *was* playing. 10. If you used iTunes, it will now be in the Pause state so will be quiet. If you used VLC the music will continue playing now the user is active again. 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. I guess the reason there is a difference between iTunes and VLC is that iTunes presumably listens to the cork notifications from CoreAudio and issues an application level pause, whereas VLC does not and thus is forcibly corked, but will automatically play again. maybe iTunes is requesting this, but then hey this option would be on enduser application level and not at audio stack level. Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. This is *exactly* the same behaviour as we promote in PulseAudio too. unfortunately I can not confirm this with iTunes either... I tested this with OSX 10.4 and OSX 10.5. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 2010-02-09 at 15:52 +0100, Markus Rechberger wrote: snip 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. snip using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. snip Am I the only one who sees a bit of a difference between what you and Colin are testing? He's testing fast user switching on the same machine and you're testing remote logins? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 9, 2010 at 4:44 PM, Ng Oon-Ee ngoo...@gmail.com wrote: On Tue, 2010-02-09 at 15:52 +0100, Markus Rechberger wrote: snip 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. snip using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. snip Am I the only one who sees a bit of a difference between what you and Colin are testing? He's testing fast user switching on the same machine and you're testing remote logins? no you are right but all together it's only about multiuser audio support. I never tested fast user switching, but for this it might make sence to lock the audio stack even though the corking mechanism is coordinated on app client level and not on stack/userlogin level. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? Comparisons to MAC and Windows have been going on for a while, and the PA guys are basically right that PA is more like Windows and Mac than the older sound systems. If I'm not mistaken, the real issue is all the very valid reasons people out in Linux land have for multi-user simultaneous access to sound. I'd say those guys are generating most of the negative PA e-mails I read, and not just on this forum. I guess the only other really nasty e-mails I read about PA are due to old unmaintained code (typically games) that have too much delay in PA. Is there any good reason that the default latency in PA for programs that don't bother setting a desired latency is greater than zero? Bill On Tue, Feb 9, 2010 at 10:49 AM, Markus Rechberger mrechber...@gmail.com wrote: On Tue, Feb 9, 2010 at 4:44 PM, Ng Oon-Ee ngoo...@gmail.com wrote: On Tue, 2010-02-09 at 15:52 +0100, Markus Rechberger wrote: snip 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. snip using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. snip Am I the only one who sees a bit of a difference between what you and Colin are testing? He's testing fast user switching on the same machine and you're testing remote logins? no you are right but all together it's only about multiuser audio support. I never tested fast user switching, but for this it might make sence to lock the audio stack even though the corking mechanism is coordinated on app client level and not on stack/userlogin level. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 9, 2010 at 5:17 PM, Bill Cox waywardg...@gmail.com wrote: The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? Comparisons to MAC and Windows have been going on for a while, and the PA guys are basically right that PA is more like Windows and Mac than the older sound systems. If I'm not mistaken, the real issue is all the very valid reasons people out in Linux land have for multi-user simultaneous access to sound. I'd say those guys are generating most of the negative PA e-mails I read, and not just on this forum. you cannot compare it with mac, on mac multiuser access works like it worked with alsa and OSS. The only point is that this behavior should be considered to be fixed up again in future. I would not wonder if a remote login in windows as a different permitted user would provide audio support. I do agree that when the user behind the PC is switched that those audio instances should be exclusive. But remote terminals are a different topic and should be handled different. the problem I see with that design is that as soon as the user logs out the PA process might vanish again so you are really stuck with the system daemon if you want to get multiuser support. although another possibility might that other PA daemons connect to the first PA instance and just pass through the first instance might do some user accounting and only shut down when all other PA instances are gone but in that case the system wide mode seems to be more elegant again... Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
They way I worked out a similar situation (I am doing an ssh from the box into the box and sometimes from a different box into it) was to setup the PA of the user I ssh as and it IS a user that I would never login directly as to use PA over the network. So as long as someone is logged in then it's PA works. You could have a couple of different configurations sitting around and do some shell trickery and start different configurations depending on the environment. Does PA support conditional config files? Maybe it can be all kept in the PA file and just set an environment variable. Fred F On Tue, Feb 9, 2010 at 11:59 AM, Markus Rechberger mrechber...@gmail.comwrote: On Tue, Feb 9, 2010 at 5:17 PM, Bill Cox waywardg...@gmail.com wrote: The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? Comparisons to MAC and Windows have been going on for a while, and the PA guys are basically right that PA is more like Windows and Mac than the older sound systems. If I'm not mistaken, the real issue is all the very valid reasons people out in Linux land have for multi-user simultaneous access to sound. I'd say those guys are generating most of the negative PA e-mails I read, and not just on this forum. you cannot compare it with mac, on mac multiuser access works like it worked with alsa and OSS. The only point is that this behavior should be considered to be fixed up again in future. I would not wonder if a remote login in windows as a different permitted user would provide audio support. I do agree that when the user behind the PC is switched that those audio instances should be exclusive. But remote terminals are a different topic and should be handled different. the problem I see with that design is that as soon as the user logs out the PA process might vanish again so you are really stuck with the system daemon if you want to get multiuser support. although another possibility might that other PA daemons connect to the first PA instance and just pass through the first instance might do some user accounting and only shut down when all other PA instances are gone but in that case the system wide mode seems to be more elegant again... Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On 9 Feb 2010, olin verbalised: OK, so that's X11. I cannot figure out what PA's mechanism for this is. I sort of get the sense, from this per-user-login server model that PA has the horrible one-persone/one-computer model of the person at the console is the person using the computer, which was inflicted on the world by Microsoft Windows. If so, this is a real design error, one that doesn't sync up with Unix, which has always had a multi-user model of the world. The model is 'the person at the console is the person near the speakers and thus the person who should get sound output when requested'. This doesn't seem like a terribly unrealistic model to me. How many computers do you know of which have speakers in a completely different place to the keyboard and screen? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 14:52 did gyre and gimble: Can you demonstrate this? In the past when I've tested this behaviour on OSX (it was quite a while ago) it behaves exactly as I described above, and I've literally just now re-tested this on a colleagues Mac (latest version): 1. Enable Fast User Switching (System Settings - Accounts - Login Options). 2. Login as user. 3. Fast user switch (top right, next to clock) to a different user. 4. With new user download and run e.g. VLC or iTunes. 5. Start playing some tunes. 6. Fast user switch back to your original user. 7. Note the blissful silence. 8. Do whatever you like with the original user login. Play tunes, check mail etc. 9. Switch back to the user who *was* playing. 10. If you used iTunes, it will now be in the Pause state so will be quiet. If you used VLC the music will continue playing now the user is active again. 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. This is a totally different scenario to what we were discussing. Please try to keep this discussion on topic rather than twisting it to suit your particular bugbear. We've discussed to death the the technical reasons why *simultaneous* output from multiple users is not supported and I've shown by example that this is the exact same basic behaviour as on OSX with regards to multiple users. You've taken a different example showing that for some bizarre reason, a user (root or otherwise) is permitted access to the sound hardware on OSX. If this is possible (and I have no reason to doubt you) then this is simply something that I would argue very strongly *against* wanting to support in PA. A random SSH user should *never* have access to various h/w devices on my machine. A security model that supports this is broken IMHO, regardless of the 0.01% of niche cases where people would like to use it. I guess the reason there is a difference between iTunes and VLC is that iTunes presumably listens to the cork notifications from CoreAudio and issues an application level pause, whereas VLC does not and thus is forcibly corked, but will automatically play again. maybe iTunes is requesting this, but then hey this option would be on enduser application level and not at audio stack level. iTunes *requests* nothing. It simply *adheres* to what it has been told is happening. The same would be true of any application that listens to the PulseAudio generated cork notifications (IOW what iTunes and VLC are doing is nigh on identical to what a native PA client can do - i.e. a PA client that listens for and takes action on cork notifications will behave like iTunes, one that doesn't have any specific support for corking will behave like VLC). Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. No idea what you mean here, but if you are think that I was suggesting some kind of iTunes is more capable than VLC then that's not really what I'm saying. Both are subject to exactly the same restrictions, it's just that iTunes presents it to the user by pausing itself and VLC does not. If iTunes had not paused itself it still would not have been able to output audio - the core fact does not change - it's simply dealing with the you are barred from producing audio signal that CoreAudio generated in a more user friendly way. This is *exactly* the same behaviour as we promote in PulseAudio too. unfortunately I can not confirm this with iTunes either... I tested this with OSX 10.4 and OSX 10.5. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. It doesn't matter if I believe it or not, the fact is that this part of the model is fundamentally broken and insecure. I mean someone roots your machine (running as nobody or apache via some week vuln in something or other) and all of a sudden they can eavesdrop on all your VoIP connections??? No thank you. At all user facing levels, for the 99.9% use case of desktop users, we behave exactly the same as OSX. In the niche case of SSH user logging in, we DO NOT support the SSH user having control of our sound hardware, and for good reason. If you wanted this second senario to be supported you would have to: 1) Convince the people in charge that this is a good idea. 2) Design a new layer that runs as a system service and takes exclusive control of the physical sound h/w. This would have to support the PA glitch-free driving mechanism. 3) Define a method of authenticating users to access
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and olin.pulse@shivers.mail0.org at 09/02/10 00:11 did gyre and gimble: OK, so that's X11. I cannot figure out what PA's mechanism for this is. I sort of get the sense, from this per-user-login server model that PA has the horrible one-persone/one-computer model of the person at the console is the person using the computer, which was inflicted on the world by Microsoft Windows. If so, this is a real design error, one that doesn't sync up with Unix, which has always had a multi-user model of the world. For X11, PA will follow where the physical *person* is. Even if the App itself is running remotely, the user is seeing the app on a local screen. And PA supports exactly the same principle but for sound. Even tho' the App is running remotely, any sound it produces is heard *locally*, not remotely. There is nothing wrong with me logging into my colleagues machine and running e.g. RhythmnBox on his machine. He currently has full, exclusive access to his machine's sound hardware, but by virtue of my local machine running PA and his machine being configured for PA output from applications, I just SSH in and run the application and the sound it produces and the display it draws are both heard/seen on *my* computer. It does not interfere with his computer in any way (other than using some CPU cycles!) and I never even ask to use his sound h/w. I've written about the various X11 scenarios here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ perhaps that'll help explain things a bit. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 9, 2010 at 6:54 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 14:52 did gyre and gimble: Can you demonstrate this? In the past when I've tested this behaviour on OSX (it was quite a while ago) it behaves exactly as I described above, and I've literally just now re-tested this on a colleagues Mac (latest version): 1. Enable Fast User Switching (System Settings - Accounts - Login Options). 2. Login as user. 3. Fast user switch (top right, next to clock) to a different user. 4. With new user download and run e.g. VLC or iTunes. 5. Start playing some tunes. 6. Fast user switch back to your original user. 7. Note the blissful silence. 8. Do whatever you like with the original user login. Play tunes, check mail etc. 9. Switch back to the user who *was* playing. 10. If you used iTunes, it will now be in the Pause state so will be quiet. If you used VLC the music will continue playing now the user is active again. 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. This is a totally different scenario to what we were discussing. Please try to keep this discussion on topic rather than twisting it to suit your particular bugbear. We've discussed to death the the technical reasons why *simultaneous* output from multiple users is not supported and I've shown by example that this is the exact same basic behaviour as on OSX with regards to multiple users. You've taken a different example showing that for some bizarre reason, a user (root or otherwise) is permitted access to the sound hardware on OSX. If this is possible (and I have no reason to doubt you) then this is simply something that I would argue very strongly *against* wanting to support in PA. A random SSH user should *never* have access to various h/w devices on my machine. A security model that supports this is broken IMHO, regardless of the 0.01% of niche cases where people would like to use it. I guess the reason there is a difference between iTunes and VLC is that iTunes presumably listens to the cork notifications from CoreAudio and issues an application level pause, whereas VLC does not and thus is forcibly corked, but will automatically play again. maybe iTunes is requesting this, but then hey this option would be on enduser application level and not at audio stack level. iTunes *requests* nothing. It simply *adheres* to what it has been told is happening. The same would be true of any application that listens to the PulseAudio generated cork notifications (IOW what iTunes and VLC are doing is nigh on identical to what a native PA client can do - i.e. a PA client that listens for and takes action on cork notifications will behave like iTunes, one that doesn't have any specific support for corking will behave like VLC). something must tell the app to 'cork' in OSX but it it no hard requirement. By the way normally only the users who are in the audio group are allowed to access audio (not entirely sure how this is handled with osx though), so it's not like a random user is allowed to access the audio device. Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. No idea what you mean here, but if you are think that I was suggesting some kind of iTunes is more capable than VLC then that's not really what I'm saying. Both are subject to exactly the same restrictions, it's just that iTunes presents it to the user by pausing itself and VLC does not. If iTunes had not paused itself it still would not have been able to output audio - the core fact does not change - it's simply dealing with the you are barred from producing audio signal that CoreAudio generated in a more user friendly way. well something must have told iTunes to pause, but it definitely was not the audio stack which forced iTunes to stop or be silent. Sending a notification to the App that it should go into a corking mode (if requested by the app) would be better. This is *exactly* the same behaviour as we promote in PulseAudio too. unfortunately I can not confirm this with iTunes either... I tested this with OSX 10.4 and OSX 10.5. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. It doesn't matter if I believe it or not, the fact is that this part of the model is fundamentally broken and insecure. I mean someone roots your machine (running as nobody or apache via some week vuln in something or other) and all of a sudden they can
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 18:25 did gyre and gimble: iTunes *requests* nothing. It simply *adheres* to what it has been told is happening. The same would be true of any application that listens to the PulseAudio generated cork notifications (IOW what iTunes and VLC are doing is nigh on identical to what a native PA client can do - i.e. a PA client that listens for and takes action on cork notifications will behave like iTunes, one that doesn't have any specific support for corking will behave like VLC). something must tell the app to 'cork' in OSX but it it no hard requirement. It's not the app that corks. The app's audio stream is corked for it and the app is told about this. The app does not have any choice in the matter. By the way normally only the users who are in the audio group are allowed to access audio (not entirely sure how this is handled with osx though), so it's not like a random user is allowed to access the audio device. The audio group is a legacy and is no longer needed. ACLs on the audio device are far more flexible. Also this only controls *physical* access to the device nodes which requires hardware mixing support to actually drive independently. Most sound hardware does NOT support hardware mixing. Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. No idea what you mean here, but if you are think that I was suggesting some kind of iTunes is more capable than VLC then that's not really what I'm saying. Both are subject to exactly the same restrictions, it's just that iTunes presents it to the user by pausing itself and VLC does not. If iTunes had not paused itself it still would not have been able to output audio - the core fact does not change - it's simply dealing with the you are barred from producing audio signal that CoreAudio generated in a more user friendly way. well something must have told iTunes to pause, but it definitely was not the audio stack which forced iTunes to stop or be silent. Yes it was. iTunes mearly paused itself because that made sense from a UI perspective. The sound system didn't say Pretty please stop playing or I'll cry and cry and cry, it basically held it's hand over it's mouth and said this will be a whole lot easier if you don't scream. Sending a notification to the App that it should go into a corking mode (if requested by the app) would be better. No it wouldn't. Corking is done by the sound system, not by the apps. If all apps *had* to implement corking support, then we'd have to reimplment *all* apps sound systems. That doesn't make any sense and besides, it's not a preference or a nice to have, it's a dictatorship-driven you have had your rights removed system. This isn't something that is specific to PA, it's lower down the stack in console kit. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. It doesn't matter if I believe it or not, the fact is that this part of the model is fundamentally broken and insecure. I mean someone roots your machine (running as nobody or apache via some week vuln in something or other) and all of a sudden they can eavesdrop on all your VoIP connections??? No thank you. of course people will capture the audio device, this is a scenario which is 99.9% unlikely. Yeah you're right, noone would ever be that nasty. Maybe you got hacked that way in the past and that's your experience, I have never seen someone hacking a system like that. Nah, you're right, no one will ever think of doing it and even if they did there are probably less than a thousand different ways they could exploit this right? Hardly worth bothering about!! But imagine even worse people who are in the videogroup are able to enable the webcam! Doh! Incase you didn't realise the above two comments were sarcastic... your point is exactly correct tho'. I don't want any other user to be able to view my webcam! That's why the groups are no longer used for device access!!! ACLs controlled by console-kit are what permits a given user access ot the webcam on any half-way modern desktop. That's the whole point!!! Do not have any users in the video group, do not have any users in the audio group. In fact I'd go the whole hog and remove those groups completely!! If someone writes down his password and pins it onto the wall the hacker might know all the passwords - what a terrible scenario! I don't disagree I'm not entirely sure what your point in relation to this discussion is tho'. How about a FM USB Transceiver which uses UAC (USB Audio Class) Why the heck should only the person sitting infront of it be allowed to use it The person sitting infront of it could listen to audio while another one could transmit audio (I do have such an engineering sample here). So you transmit something in
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 9, 2010 at 7:51 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 18:25 did gyre and gimble: iTunes *requests* nothing. It simply *adheres* to what it has been told is happening. The same would be true of any application that listens to the PulseAudio generated cork notifications (IOW what iTunes and VLC are doing is nigh on identical to what a native PA client can do - i.e. a PA client that listens for and takes action on cork notifications will behave like iTunes, one that doesn't have any specific support for corking will behave like VLC). something must tell the app to 'cork' in OSX but it it no hard requirement. It's not the app that corks. The app's audio stream is corked for it and the app is told about this. The app does not have any choice in the matter. By the way normally only the users who are in the audio group are allowed to access audio (not entirely sure how this is handled with osx though), so it's not like a random user is allowed to access the audio device. The audio group is a legacy and is no longer needed. ACLs on the audio device are far more flexible. Also this only controls *physical* access to the device nodes which requires hardware mixing support to actually drive independently. Most sound hardware does NOT support hardware mixing. Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. No idea what you mean here, but if you are think that I was suggesting some kind of iTunes is more capable than VLC then that's not really what I'm saying. Both are subject to exactly the same restrictions, it's just that iTunes presents it to the user by pausing itself and VLC does not. If iTunes had not paused itself it still would not have been able to output audio - the core fact does not change - it's simply dealing with the you are barred from producing audio signal that CoreAudio generated in a more user friendly way. well something must have told iTunes to pause, but it definitely was not the audio stack which forced iTunes to stop or be silent. Yes it was. iTunes mearly paused itself because that made sense from a UI perspective. The sound system didn't say Pretty please stop playing or I'll cry and cry and cry, it basically held it's hand over it's mouth and said this will be a whole lot easier if you don't scream. Sending a notification to the App that it should go into a corking mode (if requested by the app) would be better. No it wouldn't. Corking is done by the sound system, not by the apps. If all apps *had* to implement corking support, then we'd have to reimplment *all* apps sound systems. That doesn't make any sense and besides, it's not a preference or a nice to have, it's a dictatorship-driven you have had your rights removed system. This isn't something that is specific to PA, it's lower down the stack in console kit. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. It doesn't matter if I believe it or not, the fact is that this part of the model is fundamentally broken and insecure. I mean someone roots your machine (running as nobody or apache via some week vuln in something or other) and all of a sudden they can eavesdrop on all your VoIP connections??? No thank you. of course people will capture the audio device, this is a scenario which is 99.9% unlikely. Yeah you're right, noone would ever be that nasty. Maybe you got hacked that way in the past and that's your experience, I have never seen someone hacking a system like that. Nah, you're right, no one will ever think of doing it and even if they did there are probably less than a thousand different ways they could exploit this right? Hardly worth bothering about!! But imagine even worse people who are in the videogroup are able to enable the webcam! Doh! Incase you didn't realise the above two comments were sarcastic... your point is exactly correct tho'. I don't want any other user to be able to view my webcam! That's why the groups are no longer used for device access!!! ACLs controlled by console-kit are what permits a given user access ot the webcam on any half-way modern desktop. That's the whole point!!! Do not have any users in the video group, do not have any users in the audio group. In fact I'd go the whole hog and remove those groups completely!! If someone writes down his password and pins it onto the wall the hacker might know all the passwords - what a terrible scenario! I don't disagree I'm not entirely sure what your point in relation to this discussion is tho'. How about a FM USB Transceiver which uses UAC (USB Audio Class) Why the heck should only the person sitting infront of it be allowed to use it The person sitting infront of it could listen to audio while
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 19:07 did gyre and gimble: How about a FM USB Transceiver which uses UAC (USB Audio Class) Why the heck should only the person sitting infront of it be allowed to use it The person sitting infront of it could listen to audio while another one could transmit audio (I do have such an engineering sample here). So you transmit something in the clear and you are suprised that someone hijacks your data? Again the relevance to this discussion is lost on me I'm afraid. the user sitting infront of it could listen to FM radio, while another one is using the FM Transmit (line-out) unit. In your scenario such devices do not exist and are prohibited. If this is how the device is designed to be used, then it should present itself as two separate devices to the kernel and appropriate ACLs could be placed on each to allow different users to access it simultaneously. I see your 'designed' way just as a valid usecase as my one (which basically was requested multiple times by multiple people already). Personally I don't. The active user has control of the sound hardware. If the machine is inactive then a pseudo session can be registered (i.e. in the case of gdm login). If the active user (be it a real user or gdm) decides he wants the audio from the lower level system then they should configure their system to recieve the audio via some kind of controlled IPC mechinism and play it back accordingly. Bypassing this layer and accessing things directly is not IMO a good design. Everything is possible with the appropriate mechanisms in place and no functionality is sacrificed, but you have to be prepared to accept that old approaches will not last forever nor survive the tests of time. your scenario is definitely over engineered for many people out there. I wouldn't call this overdesign. Quite the opposite. Yes to get this rather bizarre scenario working it would be complex, but to make it work out of the box in this way in PA itself is far from simple. I've already listed the 5 relevant points that would need addressing for this to work and there are significant design hurdles to overcome there. That is what I would consider overdesign - doing something very complex to support a pretty niche use case. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Jeremy Nickurak at 09/02/10 19:24 did gyre and gimble: On Tue, Feb 9, 2010 at 09:41, Tanu Kaskinen ta...@iki.fi mailto:ta...@iki.fi wrote: That's easier said than done. Only one process can have direct access to the sound card at a time. Each user has his own pulseaudio instance running. How do you implement constant access in such scenario? I fear it would require a major redesign effort in pulseaudio. I haven't seen any concrete design proposals enabling simultaneous access for multiple users while at the same time retaining all the desirable properties that the current system has. Off the top of my head root or other system-level pulseaudio instance opens and owns the physical hardware for the entire time a computer is up. All the user pulseaudio instances connect through that. What's the downside here? Mainly due to latencies resulting from the IPC mechanism. Currently PA operates a zero-copy core, but this would likely introduce data copying. Also user access would then have to be governed by the PA process. Which user is allowed to access it and for which devices. Console-kit integration could be used to say which users are active, so we could authenticate that way in some capacity but how do you implement multi-seat device allocation with a single PA process? There are likely many other problems too but you'll probably have to wait for Lennarts comments to get a full picture. Alternatively, rely on the underlying layer to do multiplexing. If the hardware supports it, awesome. If it doesn't, let dmix handle it. Dmix is very smart but it does not support the power saving features possible in PA. This whole thing has been discussed to death, and I really don't feel like being drawn into the whole thing again. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Dnia 2010-02-09, wto o godzinie 19:31 +, Colin Guthrie pisze: I wouldn't call this overdesign. Quite the opposite. Yes to get this rather bizarre scenario working it would be complex, but to make it work out of the box in this way in PA itself is far from simple. I've already listed the 5 relevant points that would need addressing for this to work and there are significant design hurdles to overcome there. That is what I would consider overdesign - doing something very complex to support a pretty niche use case. It might drop in the same 'overdesigned' category, but maybe it would be possible to create a scenario where: 1. remote user or a daemon wants to play audio 2. PA looks for an active user session on local PC 3. the remote user's PA tries to connect (over native protocol) to the active user session 4. there's a dialog on the active user's session with 'User tries to access your audio equipment with application , allow / deny?' 5. if the active user agrees, the remote user is able to play, otherwise it remains corked until the active user changes or allows the stream to play. This would also simplify how remote tunnels are created - now you can either turn off authentication or hack the config file to only allow certain Oh, and apart from VoIP calls being eavesdropped, if someone hacks in and has access to the hardware he can hear _everything_ that is said near the microphone. Big problem. Not even root should be able to do that. -- Cheers Michał (Saviq) Sawicz signature.asc Description: To jest część wiadomości podpisana cyfrowo ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Michał Sawicz at 09/02/10 20:57 did gyre and gimble: Dnia 2010-02-09, wto o godzinie 19:31 +, Colin Guthrie pisze: I wouldn't call this overdesign. Quite the opposite. Yes to get this rather bizarre scenario working it would be complex, but to make it work out of the box in this way in PA itself is far from simple. I've already listed the 5 relevant points that would need addressing for this to work and there are significant design hurdles to overcome there. That is what I would consider overdesign - doing something very complex to support a pretty niche use case. It might drop in the same 'overdesigned' category, but maybe it would be possible to create a scenario where: 1. remote user or a daemon wants to play audio 2. PA looks for an active user session on local PC 3. the remote user's PA tries to connect (over native protocol) to the active user session 4. there's a dialog on the active user's session with 'User tries to access your audio equipment with application , allow / deny?' 5. if the active user agrees, the remote user is able to play, otherwise it remains corked until the active user changes or allows the stream to play. This would also simplify how remote tunnels are created - now you can either turn off authentication or hack the config file to only allow certain This is possible but not with the current structure. Until the authentication is successful, there can be no stream and thus it cannot be corked... but the principle is not all bad and with luck the notification framework I'll eventually commit will help with part of this approach should it be undertaken. That said, I'm not sure the complications resulting from this approach are really worth the benefits. I think we should concentrate on getting the typical use cases working as near to perfect as possible before devoting too much time on rather more exotic multi-user interaction scenarios. Oh, and apart from VoIP calls being eavesdropped, if someone hacks in and has access to the hardware he can hear _everything_ that is said near the microphone. Big problem. Not even root should be able to do that. Couldn't agree more :) -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Colin Guthrie wrote: 'Twas brillig, and Jeremy Nickurak at 09/02/10 19:24 did gyre and gimble: This whole thing has been discussed to death, and I really don't feel like being drawn into the whole thing again. From what I've read here, I'm afraid it's going to keep coming up until we solve it somehow. There are just too many people for where the ordinary PA setup (all soundcards are of exclusive use to the person logged into the current X session) is not acceptable, and worse, it isn't easy for them to either reconfigure PA, or replace PA, with something that suits their needs. I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio Let's hope we can get something constructive out of this, and I'm hopeful we can solve those people's problems, without sacrificing latency, power usage or security. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio For user Foo, the sound card sounds like it's dedicated for Foo. If this is the case the a udev rule should be written to ensure that only Foo has ACL rights on this file and any console-kit udev-acl callouts are ignored. For user Bar, I feel this is invalid. Why should user Bar have the right to output a sound any more than he has the right to display a popup window on my desktop? If either scenario is to be supported, then what I suggested elsewhere in this thread is still valid I reckon. i.e something needs to be run as the active user that acts as an agent for some kind of (system?) service that actually generates said alarm. The agent will be running as the active user and it will be responsible for playing the sound/displaying the popup. As for multi-seat, this is already in hand. Console-Kit has support for multi-seat stuff (tho' it may not be complete - I'm not overly sure here). What may still remain to be done is to tag certain devices as being for particular seats so that console-kit/udev can apply the appropriate ACLs when the set becomes active for a given user. All the multi-seat stuff is below PA tho' We'll just honour what it tells us. I don't think we don't need to add specific support for it. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio For user Foo, the sound card sounds like it's dedicated for Foo. If this is the case the a udev rule should be written to ensure that only Foo has ACL rights on this file and any console-kit udev-acl callouts are ignored. That makes sense, thanks. I added that reply to the blueprint. For user Bar, I feel this is invalid. Why should user Bar have the right to output a sound any more than he has the right to display a popup window on my desktop? Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? If either scenario is to be supported, then what I suggested elsewhere in this thread is still valid I reckon. i.e something needs to be run as the active user that acts as an agent for some kind of (system?) service that actually generates said alarm. The agent will be running as the active user and it will be responsible for playing the sound/displaying the popup. Right, this would make sense for some use cases as well and worth considering. As for multi-seat, this is already in hand. Console-Kit has support for multi-seat stuff (tho' it may not be complete - I'm not overly sure here). What may still remain to be done is to tag certain devices as being for particular seats so that console-kit/udev can apply the appropriate ACLs when the set becomes active for a given user. All the multi-seat stuff is below PA tho' We'll just honour what it tells us. I don't think we don't need to add specific support for it. And the way ck/udev tells PA what devices it can use, is through device permissions? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, Feb 10, 2010 at 7:14 AM, David Henningsson launchpad@epost.diwic.se wrote: Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio For user Foo, the sound card sounds like it's dedicated for Foo. If this is the case the a udev rule should be written to ensure that only Foo has ACL rights on this file and any console-kit udev-acl callouts are ignored. That makes sense, thanks. I added that reply to the blueprint. For user Bar, I feel this is invalid. Why should user Bar have the right to output a sound any more than he has the right to display a popup window on my desktop? Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? Also imagine TV tuners, webcams are basically handled the same way. One user might want to capture a TV movie, while the other one doesn't need access to it. The ck assignment would not be valid for this. Now imagine we have a DVB device, multiple users can access the same TV channel. While another user might stream or capture the TV content the user sitting behind the PC might watch the current tuned in TV channel. This is a not so unlikely scenario with our devices. This is also just another example where the MS-DOS like single user scenario does not fit. Best Regards, Markus If either scenario is to be supported, then what I suggested elsewhere in this thread is still valid I reckon. i.e something needs to be run as the active user that acts as an agent for some kind of (system?) service that actually generates said alarm. The agent will be running as the active user and it will be responsible for playing the sound/displaying the popup. Right, this would make sense for some use cases as well and worth considering. As for multi-seat, this is already in hand. Console-Kit has support for multi-seat stuff (tho' it may not be complete - I'm not overly sure here). What may still remain to be done is to tag certain devices as being for particular seats so that console-kit/udev can apply the appropriate ACLs when the set becomes active for a given user. All the multi-seat stuff is below PA tho' We'll just honour what it tells us. I don't think we don't need to add specific support for it. And the way ck/udev tells PA what devices it can use, is through device permissions? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] system-wide daemon
PA is a system that manages access to a hardware resource, in a network distributed context. Such a system must have mechanism for managing authentication and privileges -- one that works in a network distributed context. X11 is in a very similar position -- except that there's less call for shared access to the resources it manages (in the sense that, with X11, multiple humans usually don't want access to the same screen, keyboard or mouse at the same time). X uses ~/.Xauthority, but, these days, it mostly lifts this base mechanism up to a distributed setting by means of ssh. OK, so that's X11. I cannot figure out what PA's mechanism for this is. I sort of get the sense, from this per-user-login server model that PA has the horrible one-persone/one-computer model of the person at the console is the person using the computer, which was inflicted on the world by Microsoft Windows. If so, this is a real design error, one that doesn't sync up with Unix, which has always had a multi-user model of the world. Maybe I'm wrong. I can't figure out *what* the model is, really. When I click on padevchooser's Configure Local Sound Server entry, I get a window whose Network Server tab lets me enable network access to local sound devices. Furthermore, I can set or clear a checkbox for Don't require authentication. But I can find nowhere any description of what this authentication would be. The documentation for PulseAudio is pretty weak; it mostly says that things work; just try them out. That's not documentation. So I'm still in the dark. -Olin ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? -Olin ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] system-wide daemon
I am trying to understand PulseAudio, and have some use cases for which it's not clear to me how best to configure the system. In my living room at home, I have a pair of stereo speakers, which are connected to a linux box, which, in turn, has some large disks holding a large music collection. When you wish to play music in my home, you do it by running a program of some sort on this computer. Now, the thing is that this computer has a monitor, keyboard and mouse. Sometimes someone is logged in to this console, doing things on the computer. Sometime no one is logged in at all. Now, as I am typing this very message, I am sitting on my couch in my living room, using my notebook computer. What I would also like to do, for example, is ssh into my living room server, run rythmbox, and play some music. Perhaps my wife is logged in to the console; perhaps she isn't. Perhaps I am. That's irrelevant. My music server is a multi-user system; multiple people can be simultaneously logged in to the system, and all of them should be able to access the audio hardware. It seems to me that this is the sort of thing for which one wants a system-wide pulse daemon. Pulse Audio seems to be tuned towards the idea of having a daemon launched per login session. But I would like multiple users in my home to be able to remotely connect to my music system and run programs that send audio to the speakers. This should be completely independent of who is logged in at the console. On the other hand, I've read the PulseAudio wiki seeking enlightenment, and the wiki very clearly disrecommends using PA in system-daemon mode. It doesn't make a very compelling case of *why* system-daemon mode is a bad idea, it mostly just explains that PA will restrict functionality for security reasons if you obstinately insist on doing so. So, what's the right way to handle the use case I've outlined? -Olin ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. It's easy to get Ubuntu Karmic and Lucid to use PulseAudio in system-wide mode. For systems that require rock-solid sound, and which need to share the sound card simultaneously with multiple users, it's what I currently recomend. Long-term, I believe this situation will change, but for now, in Ubuntu, system-wide mode would be my recomendation for you. To set system-wide mode: Edit /etc/defaults/pulseaudio, and change: PULSEAUDIO_SYSTEM_START=0 to PULSEAUDIO_SYSTEM_START=1 Then, edit /etc/pulse/client.conf, and add the line autospawn = no After the line that says '#autospawn = yes'. Then, delete the file /etc/xdg/autostart/pulseaudio.desktop. Finally, disable group-based authentication to use the sound system. Edit /etc/pulse/system.pa. Find the line that reads: load-module module-native-protocol-unix and change it to read: load-module module-native-protocol-unix auth-anonymous=1 Be warned that you open yourself up to a unauthorized sound hacker attacks! Your wife could send perverse audio over your speakers without permission! Your children could spy on you through your mic without your password! If you're a bit confused, join the club. In any case, I my system works very well in system-wide mode, and for my purposes it works far better than user-mode, but I've got multiple programs running as different users that need simultaneous access to the sound card. Bill On Sun, Feb 7, 2010 at 6:54 PM, olin.pulse@shivers.mail0.org wrote: I am trying to understand PulseAudio, and have some use cases for which it's not clear to me how best to configure the system. In my living room at home, I have a pair of stereo speakers, which are connected to a linux box, which, in turn, has some large disks holding a large music collection. When you wish to play music in my home, you do it by running a program of some sort on this computer. Now, the thing is that this computer has a monitor, keyboard and mouse. Sometimes someone is logged in to this console, doing things on the computer. Sometime no one is logged in at all. Now, as I am typing this very message, I am sitting on my couch in my living room, using my notebook computer. What I would also like to do, for example, is ssh into my living room server, run rythmbox, and play some music. Perhaps my wife is logged in to the console; perhaps she isn't. Perhaps I am. That's irrelevant. My music server is a multi-user system; multiple people can be simultaneously logged in to the system, and all of them should be able to access the audio hardware. It seems to me that this is the sort of thing for which one wants a system-wide pulse daemon. Pulse Audio seems to be tuned towards the idea of having a daemon launched per login session. But I would like multiple users in my home to be able to remotely connect to my music system and run programs that send audio to the speakers. This should be completely independent of who is logged in at the console. On the other hand, I've read the PulseAudio wiki seeking enlightenment, and the wiki very clearly disrecommends using PA in system-daemon mode. It doesn't make a very compelling case of *why* system-daemon mode is a bad idea, it mostly just explains that PA will restrict functionality for security reasons if you obstinately insist on doing so. So, what's the right way to handle the use case I've outlined? -Olin ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Sun, Feb 7, 2010 at 10:54 PM, Bill Cox waywardg...@gmail.com wrote: To set system-wide mode: [...] The method for Jaunty/Karmic differs slightly from that for Lucid, but one can always look in /etc/default/pulseaudio for pointers. I try to keep this file updated. Best, -Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] System-wide daemon howto/best practices
On Wed, 29.08.07 20:38, Jan Kasprzak ([EMAIL PROTECTED]) wrote: Hi! on my home workstation I use a dual-seated setup (two monitors, two keyboards, two VGA cards, etc. - two independent users). I am looking for a way of using the sound card by both users simultaneously (I have problem that when one user's application opens the sound device and keeps it opened, the other user's ekiga cannot use it, which is quite annoying especially when receiving an incoming call). I thought system-wide PulseAudio daemon might be the correct answer. I have read http://www.pulseaudio.org/wiki/SystemWideInstance, but I am not sure about how to best configure it: * Is there any prebuilt init script for Fedora? Fedora RPMs does not seem to have any (this is a minor problem, I can write it myself). Not that I knew of. * How to tell all user's sessions use this PulseAudio daemon? Should I set an environment variable PULSE_SERVER somewhere in GDM session startup scripts? Or use the default-server directive in /etc/pulse/client.conf? You have lot of different options: You could stick it in /etc/pulse/client.conf (which is probably what I'd). You could set $PULSE_SERVER. You could leave it out entirely if the PA daemon is running locally. You could store it in the X11 root window. (see pax11publish for that) If PULSE_SERVER is not set PA will try $DISPLAY as a fallback, too. So basically, I did my best to make it work even without too much manual configuration. * What about authentication? Is a pulse-access group membership the recommended way? Or should I copy ~/.pulse-cookie to the home directories of users I want to have access to the system-wide daemon? Both is fine. pulse-access is probably the best bay though. * Should user apps access the system-wide daemon directly? I have also thought about each user having his own daemon, connected to the system-wide one by (e.g.) module-native-protocol-unix. Each time you add another layer of indirection audio latency becomes worse. Thus I'd suggest using a single system-wide instance and that should be it. OTOH more and more policy is managed by the PA daemons and hence running it per-session is much better then running it system-wide. Inside RH we had a few disucssions how to handle multi-seat setups with regards to audio best. Our conclusion was that audio cards should be treated similar to mice and keyboards: i.e. each seat gets its own pair of boxes (or a headphone) and they are not shared with anyone else. OTOH I see how sharing a sound card would be handy. So in the end we might end up with the optional solution of running a tiny/dumbed-down pa system instance which sessions connect to. But that's way down on my TODO list, and will always stay optional since it is detrimental for latency. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
