Re: [pulseaudio-discuss] Accessing audio as root
On Tue, 05.01.10 01:04, Colin Guthrie (gm...@colin.guthr.ie) wrote: I don't know if the getty system could launch a psuedo session itself so that ck doesn't specifically need to be aware of idle status - it was just my way of imagineering how I'd approach the problem which (by the sounds of things) was along the right lines (\o/) getty based logins are currently registered in CK by means of the PAM ckit connector. In the above comment I wasn't meaning the *actual* user login (I know this works fine via the PAM ck stuff) but the login prompt itself (cf the gdm graphical login with it's pseudo session). This was the whole concept of the idle thing I was suggesting and why I was expecting an idle user would be needed to handle this (cf gdm user). Sorry if my (incorrect?) terminology is misleading. We're probably mostly talking about the same thing but I'm just not describing it too well. I have discussed this with Kay now and he'd very much prefer to do this with a proper idle session that some tool (maybe some wrapper around the speakup daemon) registers in CK, instead of patching udev-acl. That should allow us to do without CK and udev-acl patches and allows non-a11y setups to stay unmodified. 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] Accessing audio as root
On Tue, Jan 5, 2010 at 8:01 AM, Lennart Poettering lenn...@poettering.net wrote: I have discussed this with Kay now and he'd very much prefer to do this with a proper idle session that some tool (maybe some wrapper around the speakup daemon) registers in CK, instead of patching udev-acl. That should allow us to do without CK and udev-acl patches and allows non-a11y setups to stay unmodified. Just double checking that I understand correctly... I still need to modify speechd-up and espeakup to deal with the sound card rights coming and going, and that if I do just this alone, I should be able to get speakup working whenever a user is logged in. This discussion of the idle session is simply about how to generate sound for login prompts on the console, correct? This would in theory allow a gdm or speakup session to own an instance of PA that hangs around rather than exiting, without locking access to the sound card as it does now if the speakup driver doesn't exit (and it doesn't). I could be wrong, but today I don't think CK follows what happens on the console in Ubuntu Karmic. Anything I do there seems to have no effect on access rights. Does this mean we also need to modify the console login program to create a user session? Thanks, Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Tue, 05.01.10 08:48, Bill Cox (waywardg...@gmail.com) wrote: On Tue, Jan 5, 2010 at 8:01 AM, Lennart Poettering lenn...@poettering.net wrote: I have discussed this with Kay now and he'd very much prefer to do this with a proper idle session that some tool (maybe some wrapper around the speakup daemon) registers in CK, instead of patching udev-acl. That should allow us to do without CK and udev-acl patches and allows non-a11y setups to stay unmodified. Just double checking that I understand correctly... I still need to modify speechd-up and espeakup to deal with the sound card rights coming and going, and that if I do just this alone, I should be able to get speakup working whenever a user is logged in. This discussion of the idle session is simply about how to generate sound for login prompts on the console, correct? This would in theory allow a gdm or speakup session to own an instance of PA that hangs around rather than exiting, without locking access to the sound card as it does now if the speakup driver doesn't exit (and it doesn't). Yes, the speakup daemons need to be modified so that they can be run as a normal user instead of root, and then can deal with devices (both audio and those special speakup kernnel devices) being assigned and taken away from them. We'd then run one of those daemons in each session and have one pseudo-session that owns the console as long as nobody is logged in on it. That way speakup would become very similar to orca and live in a nicely contained environment that closely mimics the gdm user pseudo-session that gdm maintains. In a simple list: 1) fix the speakup daemons so that they dont need root and can deal with devices being assigned to them and going away. 2) write some udev rules that make the speakup special devices ACL managed the same way as audio devices already are. (i.e. just set ACL_MANAGE=1 for them, it's a one-liner) 3) write a little wrapper for the speakup daemons that sets up a pseudo-session in ck that owns the console and then runs the speakup daemon in it. done. I could be wrong, but today I don't think CK follows what happens on the console in Ubuntu Karmic. Anything I do there seems to have no effect on access rights. Does this mean we also need to modify the console login program to create a user session? The whole point of ConsoleKit is to follow who's logged in. Are you suggesting that if you login on the console ck-list-sessions does not list that session? If that's the case your really should have a word with the Ubuntu developers... 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] Accessing audio as root
On Tue, Jan 5, 2010 at 9:19 AM, Lennart Poettering lenn...@poettering.net wrote: Yes, the speakup daemons need to be modified so that they can be run as a normal user instead of root, and then can deal with devices (both audio and those special speakup kernnel devices) being assigned and taken away from them. We'd then run one of those daemons in each session and have one pseudo-session that owns the console as long as nobody is logged in on it. That way speakup would become very similar to orca and live in a nicely contained environment that closely mimics the gdm user pseudo-session that gdm maintains. In a simple list: 1) fix the speakup daemons so that they dont need root and can deal with devices being assigned to them and going away. 2) write some udev rules that make the speakup special devices ACL managed the same way as audio devices already are. (i.e. just set ACL_MANAGE=1 for them, it's a one-liner) 3) write a little wrapper for the speakup daemons that sets up a pseudo-session in ck that owns the console and then runs the speakup daemon in it. done. Thanks for the summary. I may not get to this until summer, but I'm on the case. This is very helpful. The whole point of ConsoleKit is to follow who's logged in. Are you suggesting that if you login on the console ck-list-sessions does not list that session? If that's the case your really should have a word with the Ubuntu developers... I was wrong. What's going on is that PA does not launch automatically when I login, and that had me confused. Sessions do seem to be tracked, and it does seem to know which is active. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Bill Cox at 05/01/10 15:12 did gyre and gimble: I was wrong. What's going on is that PA does not launch automatically when I login, and that had me confused. Sessions do seem to be tracked, and it does seem to know which is active. That's expected. PA will be launched as needed e.g. when something tries to output sound (either via alsa if the alsa-pulseaudio plugin is configured as the default alsa device, or via any native Pulseaudio clients - essentially anything that uses libpulse). For speech stuff you can't follow this model as you need it to start as soon as there is something to say. The process of starting your speech app should trigger PA startup via the above auto-spawning system. 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] Accessing audio as root
On Tue, 05.01.10 10:12, Bill Cox (waywardg...@gmail.com) wrote: The whole point of ConsoleKit is to follow who's logged in. Are you suggesting that if you login on the console ck-list-sessions does not list that session? If that's the case your really should have a word with the Ubuntu developers... I was wrong. What's going on is that PA does not launch automatically when I login, and that had me confused. Sessions do seem to be tracked, and it does seem to know which is active. Yepp, normal login sessions dont have a proper session manager, that makes it hard to start services automatically for them. It's one of the reasons console logins really should go away for everything but the most low-level debugging/administration. To remedy that we start PA on-demand on the consoles, i.e. on first use. 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] Accessing audio as root
ma, 2010-01-04 kello 09:37 +, Colin Guthrie kirjoitti: As for the next stage I'm not an expert on this but I think you can try adding: [Element IEC985 Optical Raw] switch = mute switch = mute makes the mixer element state follow pulseaudio's sink mute state, and I don't think you meant to do that. Use switch = off to set the element always off or switch = on to set it always on. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Tanu Kaskinen at 04/01/10 14:26 did gyre and gimble: ma, 2010-01-04 kello 09:37 +, Colin Guthrie kirjoitti: As for the next stage I'm not an expert on this but I think you can try adding: [Element IEC985 Optical Raw] switch = mute switch = mute makes the mixer element state follow pulseaudio's sink mute state, and I don't think you meant to do that. Use switch = off to set the element always off or switch = on to set it always on. Thank you :) /me really does have to read up on this stuff at some point. 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] Accessing audio as root
'Twas brillig, and Daniel Chen at 04/01/10 15:04 did gyre and gimble: On Mon, Jan 4, 2010 at 9:26 AM, Tanu Kaskinen ta...@iki.fi wrote: switch = mute makes the mixer element state follow pulseaudio's sink mute state, and I don't think you meant to do that. Use switch = off to set the element always off or switch = on to set it always on. FWIW, Ubuntu has carried this workaround for Live and Audigy devices, but it's only a workaround. It should be fixed in ALSA, and I'll be pushing a patch to alsa-utils (for the init db) to do this properly. /me has a look to copying that for Gene -- 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] Accessing audio as root
'Twas brillig, and Colin Guthrie at 04/01/10 15:33 did gyre and gimble: 'Twas brillig, and Daniel Chen at 04/01/10 15:04 did gyre and gimble: On Mon, Jan 4, 2010 at 9:26 AM, Tanu Kaskinen ta...@iki.fi wrote: switch = mute makes the mixer element state follow pulseaudio's sink mute state, and I don't think you meant to do that. Use switch = off to set the element always off or switch = on to set it always on. FWIW, Ubuntu has carried this workaround for Live and Audigy devices, but it's only a workaround. It should be fixed in ALSA, and I'll be pushing a patch to alsa-utils (for the init db) to do this properly. /me has a look to copying that for Gene Actually is this safe to do - i.e. disabling it wholesale? Is it not used for digital output in some capacity (e.g. if the user picks a digital profile)? Or is it perfectly safe to just turn it off all the time? I don't have this h/w so can't easily test... 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] Accessing audio as root
On Mon, Jan 4, 2010 at 10:53 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Actually is this safe to do - i.e. disabling it wholesale? Is it not used for digital output in some capacity (e.g. if the user picks a digital profile)? Or is it perfectly safe to just turn it off all the time? I don't have this h/w so can't easily test... Using off is only safe for analog output. To correctly fix this issue on Lives/Audigys, we need: 1) alsactl to mute 'IEC958 Optical Raw' at boot via its init db 2) PA to set off for above mixer control for analog profiles and on for IEC958-enabled ones I chatted briefly with Lennart some time ago on IRC about this mixer control, and he was of the opinion that ALSA needs to correctly set it at boot (which would be accomplished via (1)). Thanks! -Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Fri, 01.01.10 22:25, Bill Cox (waywardg...@gmail.com) wrote: On Thu, Dec 17, 2009 at 4:52 AM, Lennart Poettering lenn...@poettering.net wrote: I don't see why anyone would want to have audio when changing to root for admin purposes. Playing music certainly does not fall under admin purposes. Ever consider what happens when a blind user switches to root, and his sound card stop speaking? This is no hypothetical situation, like someone trying to spy on me through Alsa by taking over my mike. It is. You should not run GUIs as root. And as long as the UI is in the terminal only everything should be fine. 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] Accessing audio as root
On Fri, 01.01.10 22:42, Bill Cox (waywardg...@gmail.com) wrote: On Wed, Dec 23, 2009 at 6:57 AM, Lennart Poettering lenn...@poettering.net wrote: And this is the problem because it works with alsa, simply add every user you want to give audio access to the audio group and it worked. Even with OSS this worked. But PA breaks this behaviour. First of all, we broke exactly nothing. You can always bypass PA and do stuff like this. Secondly, allowing access to the audio device to all users is a security hole as I tried to explain quite a few times. Allowing that means a user can evesdrop into your voip calls, he can even completely monitor whatever you say when you sit in front of your computer. How can I bypass PA on a Ubuntu Karmic or Lucid? If I disable user-land pulseaudio, several applications break, including the volume control. PulseAudio has been Vulcan mind-melded into the system. If you know of a realistic way to bypass PulseAudio, by all means, please state it! Simply use the front: device string when using ALSA instead of the default of default or pulse. 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] Accessing audio as root
On Fri, 01.01.10 23:13, Bill Cox (waywardg...@gmail.com) wrote: On Wed, Dec 23, 2009 at 9:13 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Halim Sahin at 23/12/09 13:24 did gyre and gimble: The Problem can be summarized in one sentence: Pulseaudio currently breaks multiuser systems and is only useful for one-user-desktop. Actually no, the exact opposite. PA works very well for multi user desktops. Hi, Col. Let me say I'm beginning to be a fan of your posts, as I read more of them. This is probably an Ubuntu issue, but in Karmic and Lucid, Switch User does not change the permissions for the sound card, and the new user will be mute. It's a fairly minor bug... the work-around is logout and log back in. IMO, Halim's more important comment was that PulseAudio breaks accessibility. Speakup is either the #1 or #2 most popular Linux accessibility program for the blind and visually impaired. It starts at boot, as it should, so a blind person can hear what's going on. Gdm kills PulseAudio when a user logs in. Speakup runs forever, and it' PulseAudio process hangs around forever, locking up the sound card, so the user can't get any sound in Gnome. I dont see why the speech tools should be handled in any way different from the other acessibility tools we ship: in that they are part of the session. While I am no accessibility expert I am kinda sure that on Fedora all accessibility stuff is run inside the user session and the gdm pseudo-session so that the fully a11y features are available both before and after the login. 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] Accessing audio as root
On Fri, 01.01.10 23:50, Bill Cox (waywardg...@gmail.com) wrote: On Fedora at least the screenreader runs as normal process in the gdm pseudo-session which also happens to run a PA instance. So everything should be fine here, and I am quite sure this is not only done on Fedora this way but all other distributions that use a current version of gdm. Lennart, let me explain how blind people use Linux. There are TWO applications in common use - Orca and Speakup. Actually, there's a third - emacspeak, but let's not go there, yet. Orca is the screen reader that you are talking about. It runs as user, and can be made to work well with PulseAudio. I've personally helped in that effort (I wrote a new pulseaudio driver for it). The other critical application is Speakup. It runs as a kernel module and speaks every bit of console output during the boot process. Many blind people rely heavily on Speakup, and only use Orca for websites that require Firefox to read. Hmmm, speakup is not supported in fedora anymore, afaik. The kernel patch never got merged upstream, did it? And there are no plans for that either, are there? It doesn't really particularly increase my interest in supporting something like this if there is no push to get this merged upstream into kernels and the major distributions. In Fedora our plans are mostly to get rid of the console entirely in the long run anyway, its not shown anymore by default already. But anyway, if we want to support this, how was the traditional handing over of the audio device done between speakup and the orca tts stuff done? Why isnt the speakup tts daemon run inside a pseudo-session similar to how gdm handles this when running orca inside of a pseudo-session? To me it sounds that if we want to do the handover properly anyway the cleanest way would be for speakup to simply call into ckit to register a pseudo-session. Then during bootup we would first run that speakup tts daemon in a speakup ck session. Then, when gdm starts up we'd run orca in the gdm session, and finally run orca in the user sessio, and hence have two handovers in the whole process: from speakup to gdm and from gdm to proper gnome. speaking all console output to the user. The blind don't give a hoot how we get speach from /dev/speakup_soft to the sound card. It just has to happen. Today, on every pulseaudio enabled system I know of, this does not work properly. I tried setting speakup to use alsa, and it works, right up until pulseaudio for gdm starts. After that, speakup is mute. Is there any way for pulseaudio to share the sound card with speakup/alsa? Why do you need speakup anymore after gdm is started up? 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] Accessing audio as root
On Sat, 02.01.10 16:52, Colin Guthrie (gm...@colin.guthr.ie) wrote: I'm not quite sure how this works. When a speakup client wants access to the sound card, it could request access at high priority, and then plays it's sound. How would it hand back the sound card to the other user and uncork it? If this were automatic once the queue was empty for say one second, that would be great. Is this the sort of thing we can do with PA/CK? While this would theoretically work, I think it's probably not needed. The reservation system is really meant for interacting with jack and while it's not exclusive, I think it's not really an appropriate technique to solve this problem. I think the general concept of the speech dispatchers running as a system service is the bit that needs re-thought I agree. and that adding hooks to consolekit (if they don't exist) and the concept of an idle user are probably more practical long term solutions. idle user? By that you mean some pseudo user session that the speakup daemon could be run under? If so, I agree. 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] Accessing audio as root
'Twas brillig, and Daniel Chen at 04/01/10 17:03 did gyre and gimble: On Mon, Jan 4, 2010 at 10:53 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Actually is this safe to do - i.e. disabling it wholesale? Is it not used for digital output in some capacity (e.g. if the user picks a digital profile)? Or is it perfectly safe to just turn it off all the time? I don't have this h/w so can't easily test... Using off is only safe for analog output. To correctly fix this issue on Lives/Audigys, we need: 1) alsactl to mute 'IEC958 Optical Raw' at boot via its init db 2) PA to set off for above mixer control for analog profiles and on for IEC958-enabled ones I chatted briefly with Lennart some time ago on IRC about this mixer control, and he was of the opinion that ALSA needs to correctly set it at boot (which would be accomplished via (1)). D'oh, I forgot that the patch was to the analog-output.conf.common file... silly me. I'll copy the same fix for the time being. Thanks :) 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] Accessing audio as root
Hi, Lennart. The blind run all sorts of GUI-driven applications like Synaptic, from the System/Administration menu. Howeve, Orca makes these applications accessible when things are working correctly. I agree that we don't want people to login through gdm as root. They do things like su to root and launch Synaptic all the time. It currently works fine. The primary problem I'm running into is that the console screens (Ctrl+Alt+F1-7) aren't read by Orca, they're read by speakup, and speakup currently is very diffiicult to get talking with user-land PulseAudio. I'm not saying impossible, but difficult because speakup is a kernel module. I'll work on this, or some other workaround, so that the version of Vinux/Ubuntu I want to publish in the Fall can have PA back in user mode. The best way to do this is still unclear to me, but I agree pulseaudio should run in user mode. On Mon, Jan 4, 2010 at 1:29 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 01.01.10 22:25, Bill Cox (waywardg...@gmail.com) wrote: On Thu, Dec 17, 2009 at 4:52 AM, Lennart Poettering lenn...@poettering.net wrote: I don't see why anyone would want to have audio when changing to root for admin purposes. Playing music certainly does not fall under admin purposes. Ever consider what happens when a blind user switches to root, and his sound card stop speaking? This is no hypothetical situation, like someone trying to spy on me through Alsa by taking over my mike. It is. You should not run GUIs as root. And as long as the UI is in the terminal only everything should be fine. 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] Accessing audio as root
'Twas brillig, and Lennart Poettering at 04/01/10 19:06 did gyre and gimble: I agree. and that adding hooks to consolekit (if they don't exist) and the concept of an idle user are probably more practical long term solutions. idle user? By that you mean some pseudo user session that the speakup daemon could be run under? If so, I agree. Yeah, the idea I was generally blundering around was that the idle user was a ck psuedo session that is active when no other session is marked as active - e.g. while sitting at a tty login prompt. I don't know if the getty system could launch a psuedo session itself so that ck doesn't specifically need to be aware of idle status - it was just my way of imagineering how I'd approach the problem which (by the sounds of things) was along the right lines (\o/) 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] Accessing audio as root
On Sat, 02.01.10 16:03, Bill Cox (waywardg...@gmail.com) wrote: Hi, Col. I'm willing to try the aproach you suggest, but I'd like to debate the implementation some more. If I understand correctly, I can use CK to determine whenever the sound card permissions are moved to a new user (which is basically whenever a user takes over the seat, except as root), and can then launch the various accessibility apps the user needs as that user. CK will inform you about session switches. However it won't run applications for you as the user. More importantly, it is generally not recommended to really watch CK if all you really are interested to get notifications when access to the audio device comes and goes away for your user. If you want to do that, then watch the device access modes directly via inotify() and access(). That is far from trivial however, because ALSA has an entire farm of device nodes, and watching them correctly and race-free is kinda hard. 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] Accessing audio as root
On Mon, Jan 4, 2010 at 1:35 PM, Lennart Poettering lenn...@poettering.net wrote: I dont see why the speech tools should be handled in any way different from the other acessibility tools we ship: in that they are part of the session. While I am no accessibility expert I am kinda sure that on Fedora all accessibility stuff is run inside the user session and the gdm pseudo-session so that the fully a11y features are available both before and after the login. For reading consoles, we use speakup, which is a kernel module. With the speakup_soft kernel module, speakup makes the text to be spoken available through /dev/softsynth. There are two different popular packages for speaking the text read from from /dev/softsynth. The most popular is the least flexible, but blind users like that it almost always works: espeakup. It runs as root, reads from /dev/softsynth, and calls espeak to say the text. More powerful, but less popular is speechd-up, whierch reads from /dev/softsynth and forwards the text to a system-wide speech-dispatcher daemon. Speech-dispatcher enables the user to use many different voices for speech synthesis, not just espeak. We've got a new speech-dispatcher pulseaudio driver which works very well, but the system-wide speech-dispatcher daemon is causing problems. I can get it to use the gdm copy of pulseaudio, but since this copy of speech-dispatcher hangs around forever, and because I always need to be able to get speech from the consoles, it causes gdm's PA instance to hang around, makeing the audio card unavailable to user sessions. Colin and Luke have suggested using CK to deal with this, by killing off speech-dispatcher and speechd-up when the user logs in through gdm, and restarting it when they log out. However, I am not convinced we should be killing off the speech-dispatcher process for the consoles, ever. I might be persuaded, but I am very concerned that the audio from the consoles remain reliable. The blind use this, for example, to fix X11 problems we all run into sometimes. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, 03.01.10 07:41, Bill Cox (waywardg...@gmail.com) wrote: Hi, Colin. I disagree that speech-dispatcher and speechd-up are broken and need to be fixed. speechd-up is a root daemon attached to the /dev/softsynth device. I see no utility in having multiple copies of it. Speech-dispatcher opens an IP port to act as a speech server over the network. It's kind of a silly feature, but why should I second-guess the speech-dispatchers developers and break it? Why do you second-guess us, but not them? In the long run device access for root wont work anyway, for example, when you acre about more than ALSA kernel devices, such as bluetooth or other stuff that might need user supplied security credentials. audio output as root is broken. IMO, what's broken is PA. I can't in Ubuntu get two copies running on the same machine without borking the sound system. If PA can't even do it, why should I mangle all the accessibility apps out there by making them try to follow PA's overly complex model? Works fine here. If two users log in then access to the audio device is handed over to the active user as soon as you switch to it and removed from now inactive user. Audio is automatically paused for inactive users and resumed as soon as they become active again. This has to be a screaming violation of the KISS rule. The sound system is a bit complex. Fine. To use it, you need to make all your apps complex? Really? First of all, PA is really not that complex in this area. We simply watch the permissions on the device nodes and close the device/pause playback if we loose access and reopen the device/resume playback if we get access again. From a high-level perspective there is nothing easier than that. Secondly, the whole udev/CK logic has originally been designed independantly of PA. If you thinkg that PA is overcomplex in this design, then I'd like to ask you to redirect your complains to the udev/CK folks. The complexity has to be contained. It can't keep leaking out of PA into the rest of the system, making it more and more unstable as it goes. That's FUD. And that's why I will ignore it. 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] Accessing audio as root
On Sun, 03.01.10 12:29, Gene Heskett (gene.hesk...@gmail.com) wrote: So, in my simplistic and user-centric point-of-view, I wonder if speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio sink, with the appropriate modules, of course. It starts before the user logs in and only exits after the user has logged out, of course. The reasoning behind my proposal is simply that root is system-wide by definition (in my understanding), hence why all Colin's proposals have involved speechd-up running as a particular user while all your replies have mentioned root access to pulse Regardless, this problem for the visually impaired is one that needs to be addressed ASAP before we have a whole battalion of lawyers from the ACLU challenging us all in courts that we don't, by the very nature of linux, have the funds to defend against. So IMNSHO, it is something that must be done, and damn the reasons for architecting PA the way it currently is. It really is that simple. You know, I work particularly well if I am threatened. Especially if those threats are completely made up. 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] Accessing audio as root
'Twas brillig, and Bill Cox at 04/01/10 19:43 did gyre and gimble: Colin and Luke have suggested using CK to deal with this, by killing off speech-dispatcher and speechd-up when the user logs in through gdm, and restarting it when they log out. Note that I wasn't really suggesting that it was killed off per-se. Just that it became a session daemon (like PA is) and that an idle user session was run when the system was idle. This would have the effect of starting it automagically when the system became idle (which implies being at a login prompt) and that it would die off when the system became active (not as a direct result of becomeing active but because the idle session was effectively over/stopped) whereby a users own version of the app could be run instead to take over after they were logged in. That said, Lennart has now clarified how the tty logins are running (tts) and basically that it itself should run a pseudo session jsut like gdm. This seems pretty sensible. 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] Accessing audio as root
On Sun, 03.01.10 21:26, Ng Oon-Ee (ngoo...@gmail.com) wrote: On Sun, 2010-01-03 at 07:41 -0500, Bill Cox wrote: Hi, Colin. I disagree that speech-dispatcher and speechd-up are broken and need to be fixed. speechd-up is a root daemon attached to the /dev/softsynth device. I see no utility in having multiple copies of it. Speech-dispatcher opens an IP port to act as a speech server over the network. It's kind of a silly feature, but why should I second-guess the speech-dispatchers developers and break it? IMO, what's broken is PA. I can't in Ubuntu get two copies running on the same machine without borking the sound system. If PA can't even do it, why should I mangle all the accessibility apps out there by making them try to follow PA's overly complex model? This has to be a screaming violation of the KISS rule. The sound system is a bit complex. Fine. To use it, you need to make all your apps complex? Really? The complexity has to be contained. It can't keep leaking out of PA into the rest of the system, making it more and more unstable as it goes. Bill IMO from what I've read so far, PA's model is one instance per user. Whether or not its 'overly complex' depends on point-of-view, since this is the same model used by (for example) X11 and jackd. I believe that, in a multi-user system, user-space apps and services should be one instance per user. Of course, I can see how this could be 'overly complex' from a developmental point of view, but its really a matter of the way you view your system. On the other hand, your app (speechd-up) is by its very nature a one instance per system app, as all apps which run as root are (should be?). Not knowing much about how it works, I can just state my belief that it won't be easy to change. I don't think it is the very nature of a tts daemnon to be per-system. Not at all. It's something per session/seat by its very nature if you ask me. If you move a session between two seats (whcih we plan to allowa in the longer run) or if you access a session remotely, then the tts daemon needs to output its audio on the sound card that belongs to the keyboard/screen (i.e. seat) the user happens to sit at, and certainly not on the sound card that is built into the server that stands 50km away or where the session was originally started on. 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] Accessing audio as root
Hi, Lennart. I beg you to not work towards eliminating the consoles. Speakup is not only popular, but easily installed as a module in Ubuntu, with 'm-a a-i speakup-souce'. Even sighted users prefer to have those consoles available when X goes nuts, and for the blind, they need it whenever speech stops, which happens whenever X11, Compiz/Metacity, Orca, speech-dispatcher, or PA stops working. It's the nature of open source software that users break it often, and they need the consoles to get back on track. Many blind users use the consoles mainly, and only switch to Gnome to access web sites that can't be handled by text-based browsers like elinks. Users need the consoles, and thus speakup, after logging in through gdm for several reasons. Most blind users feel speakup is a better console driver than Orca driving gnome-terminal, and they spend as little time in Gnome as possible. I hear it integrates well with Braille displays. To put it simply, I cannot even imagine creating a Vinux distro (linux for the blind) without speakup and consoles! Bill On Mon, Jan 4, 2010 at 1:58 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 01.01.10 23:50, Bill Cox (waywardg...@gmail.com) wrote: On Fedora at least the screenreader runs as normal process in the gdm pseudo-session which also happens to run a PA instance. So everything should be fine here, and I am quite sure this is not only done on Fedora this way but all other distributions that use a current version of gdm. Lennart, let me explain how blind people use Linux. There are TWO applications in common use - Orca and Speakup. Actually, there's a third - emacspeak, but let's not go there, yet. Orca is the screen reader that you are talking about. It runs as user, and can be made to work well with PulseAudio. I've personally helped in that effort (I wrote a new pulseaudio driver for it). The other critical application is Speakup. It runs as a kernel module and speaks every bit of console output during the boot process. Many blind people rely heavily on Speakup, and only use Orca for websites that require Firefox to read. Hmmm, speakup is not supported in fedora anymore, afaik. The kernel patch never got merged upstream, did it? And there are no plans for that either, are there? It doesn't really particularly increase my interest in supporting something like this if there is no push to get this merged upstream into kernels and the major distributions. In Fedora our plans are mostly to get rid of the console entirely in the long run anyway, its not shown anymore by default already. But anyway, if we want to support this, how was the traditional handing over of the audio device done between speakup and the orca tts stuff done? Why isnt the speakup tts daemon run inside a pseudo-session similar to how gdm handles this when running orca inside of a pseudo-session? To me it sounds that if we want to do the handover properly anyway the cleanest way would be for speakup to simply call into ckit to register a pseudo-session. Then during bootup we would first run that speakup tts daemon in a speakup ck session. Then, when gdm starts up we'd run orca in the gdm session, and finally run orca in the user sessio, and hence have two handovers in the whole process: from speakup to gdm and from gdm to proper gnome. speaking all console output to the user. The blind don't give a hoot how we get speach from /dev/speakup_soft to the sound card. It just has to happen. Today, on every pulseaudio enabled system I know of, this does not work properly. I tried setting speakup to use alsa, and it works, right up until pulseaudio for gdm starts. After that, speakup is mute. Is there any way for pulseaudio to share the sound card with speakup/alsa? Why do you need speakup anymore after gdm is started up? 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] Accessing audio as root
On Sun, 03.01.10 14:21, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Ng Oon-Ee at 03/01/10 13:26 did gyre and gimble: So, in my simplistic and user-centric point-of-view, I wonder if speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio sink, with the appropriate modules, of course. It starts before the user logs in and only exits after the user has logged out, of course. The reasoning behind my proposal is simply that root is system-wide by definition (in my understanding), hence why all Colin's proposals have involved speechd-up running as a particular user while all your replies have mentioned root access to pulse I guess a possibility is the following: 1. Make console-kit aware of the idle state as before. 2. Make the speechd-up or speech-dispatcher headless. i.e. all they do is open a pipe (fifo) and pump their synthesised speech to it - they do not actually output audio itself. 3. Write a PA module that acts as a pulse client that opens that pipe and outputs the sound (in actual fact, we could use a combination of module-pipe-source and module-loopback for this without writing a single line of code in PA). 4. Place a script in: /usr/lib/ConsoleKit/run-session.d or /etc/ConsoleKit/run-session.d (I'm not sure which is best) which basically does the following (see /usr/bin/start-pulseaudio-x11): /usr/bin/pulseaudio --start --log-target=syslog $@ /usr/bin/pactl load-module module-pipe-source source_name=a11y file=/tmp/a11y.socket /dev/null /usr/bin/pactl load-module module-loopback source=a11y /dev/null (or something like the above - I could have gotten arguments wrong and you may want some channels/rate etc. stuff going on). There may also need to be something setup to stop PA from exiting after an idle timeout. With all that in place things may just work. Obviously speechd-up would have to support multiple clients opening the /tmp/a11y.socket file (and it probably shouldn't actually be in /tmp!). Does that fit better with your model of things? Not sure i am convinced. You'd need to switch which PA instance actually plays back audio when the session changes. Othewise all sessions would play (or try to play) audio at the same time. 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] Accessing audio as root
On Mon, Jan 4, 2010 at 2:26 PM, Lennart Poettering lenn...@poettering.net wrote: ... an alternative could be to fix speakup to simply watch CK and disable itself as long as long as somebody is logged in. Users need to be able to press Ctrl+Alt+F1 at any time and get to a speeking console. It can't ever go away. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, 03.01.10 16:34, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Bill Cox at 03/01/10 16:23 did gyre and gimble: Speechd-up isn't the only root level sound source that's out there. Espeakup is another alternative to speechd-up which is currently much more popular, but limited in that it can only use the espeak voice. From the point of view of developers for such packages, they just want to write to a sound output interface. Espeakup uses portaudio, and frankly, I don't want to rewrite that interface (one is enough for me). These processes, even speechd-up, set custom buffering parameters in PA (speechd-up requires the tlength paramter to be much shorter than default). Well in the situation I'm proposing, the speechd-up would actually just write it's audio to a pipe (totally bypassing pulse client API), and it would be up to module-pipe-source and module-loopback to act as the pulse client, reading from the pipe and actually doing the output. The buffering metrics can be somewhat adjusted when loading module-loopback. This wont fly. m-p-s assumes the audio you pass to it is clocked. and m-l depends on that. However the tts audio will not be clocked properly, and hence things will make boom.. That said, writing a simple module reads audio data from a pipe and passes directly to a sink should be trivial to do. Note however that on Unix pipes cannot be used to distribute data to multiple processes. 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] Accessing audio as root
'Twas brillig, and Bill Cox at 04/01/10 20:01 did gyre and gimble: On Mon, Jan 4, 2010 at 2:26 PM, Lennart Poettering lenn...@poettering.net wrote: ... an alternative could be to fix speakup to simply watch CK and disable itself as long as long as somebody is logged in. Users need to be able to press Ctrl+Alt+F1 at any time and get to a speeking console. It can't ever go away. You over-pruned the quoted text. Lennart carries on (the very next paragraph) to explain: Effectively this means that instead of running PA for the tts daemon which then watches access on the audio device nodes, it [meaning speechd-up et al.] would have to watch CK and enable/disable itself as soon as somebody logs out or logs in and could *directly access the audio devices*. (Emphasis and [] mine) The idea being that once the user logs in, a user-spawned process takes over from there (which is basically what I was suggesting too albeit avoiding running PA for the idle session). 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] Accessing audio as root
On Mon, Jan 4, 2010 at 2:37 PM, Lennart Poettering lenn...@poettering.net wrote: Also, the sepakup device access should be handled by udev-acl as well. That would probably require non-trivial patching in the speakup tts daemon though. I'm completely ignorant of udev-acl, but if this is the thing that moves around device access rights when you switch users, then I agree. If we could pass around /dev/soft_synth rights like we do the sound card, we could make this work with user-space code. The critical thing is that /dev/soft_synth rights must always follow the audio card rights. Is it easy to make this work very reliably with CK/udev? If this is only a kernel module change, I will sign up to do that. It would be great if we could leave espeakup and speechd-up mostly untouched. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Mon, Jan 4, 2010 at 8:51 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 03.01.10 07:41, Bill Cox (waywardg...@gmail.com) wrote: Hi, Colin. I disagree that speech-dispatcher and speechd-up are broken and need to be fixed. speechd-up is a root daemon attached to the /dev/softsynth device. I see no utility in having multiple copies of it. Speech-dispatcher opens an IP port to act as a speech server over the network. It's kind of a silly feature, but why should I second-guess the speech-dispatchers developers and break it? Why do you second-guess us, but not them? In the long run device access for root wont work anyway, for example, when you acre about more than ALSA kernel devices, such as bluetooth or other stuff that might need user supplied security credentials. audio output as root is broken. it's not but it doesn't matter just about every other user has the same issue. Root has full access to the hardware (eg. doing maintenance, testing the hardware modifying global settings etc.). IMO, what's broken is PA. I can't in Ubuntu get two copies running on the same machine without borking the sound system. If PA can't even do it, why should I mangle all the accessibility apps out there by making them try to follow PA's overly complex model? Works fine here. If two users log in then access to the audio device is handed over to the active user as soon as you switch to it and removed from now inactive user. Audio is automatically paused for inactive users and resumed as soon as they become active again. We are fine with your idea but bring back compatibility to the old audio system, some users want it and need it. This has to be a screaming violation of the KISS rule. The sound system is a bit complex. Fine. To use it, you need to make all your apps complex? Really? agreed. First of all, PA is really not that complex in this area. We simply watch the permissions on the device nodes and close the device/pause playback if we loose access and reopen the device/resume playback if we get access again. From a high-level perspective there is nothing easier than that. Secondly, the whole udev/CK logic has originally been designed independantly of PA. If you thinkg that PA is overcomplex in this design, then I'd like to ask you to redirect your complains to the udev/CK folks. The complexity has to be contained. It can't keep leaking out of PA into the rest of the system, making it more and more unstable as it goes. That's FUD. And that's why I will ignore it. it's not it's just a matter of which system someone is running and what problem someone is experiencing. http://sundtek.de/support/pulseaudio.wav Ubuntu 9.10, don't know how to reproduce it (sure it doesn't help but how do you expect users to debug issues which come up randomly after a while?) Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Mon, 04.01.10 14:59, Bill Cox (waywardg...@gmail.com) wrote: Hi, Lennart. I beg you to not work towards eliminating the consoles. Speakup is not only popular, but easily installed as a module in Ubuntu, with 'm-a a-i speakup-souce'. It's not me who is setting the agenda here, its mostly the X/video folks whose plans that are. Note that droppping the console does not necessarily mean there would be no replacement for rescue/admin purposes, that does not depend on the full X stack. That would probably live in userspace though. But then again, I probably should not comment too much about the X/video plans, given that I dont really work on that. Users need the consoles, and thus speakup, after logging in through gdm for several reasons. Most blind users feel speakup is a better console driver than Orca driving gnome-terminal, and they spend as little time in Gnome as possible. I hear it integrates well with Braille displays. Right. So why not fix orca and make everything work fine in Gnome? I mean, lets fix things properly, not carry on with kludges. 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] Accessing audio as root
On Mon, 04.01.10 19:36, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Lennart Poettering at 04/01/10 19:06 did gyre and gimble: I agree. and that adding hooks to consolekit (if they don't exist) and the concept of an idle user are probably more practical long term solutions. idle user? By that you mean some pseudo user session that the speakup daemon could be run under? If so, I agree. Yeah, the idea I was generally blundering around was that the idle user was a ck psuedo session that is active when no other session is marked as active - e.g. while sitting at a tty login prompt. I don't know if the getty system could launch a psuedo session itself so that ck doesn't specifically need to be aware of idle status - it was just my way of imagineering how I'd approach the problem which (by the sounds of things) was along the right lines (\o/) getty based logins are currently registered in CK by means of the PAM ckit connector. 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] Accessing audio as root
On Mon, 04.01.10 21:36, Markus Rechberger (mrechber...@gmail.com) wrote: Why do you second-guess us, but not them? In the long run device access for root wont work anyway, for example, when you acre about more than ALSA kernel devices, such as bluetooth or other stuff that might need user supplied security credentials. audio output as root is broken. it's not but it doesn't matter just about every other user has the same issue. Root has full access to the hardware (eg. doing maintenance, testing the hardware modifying global settings etc.). Yes, and we never broke that. But anyway, it's probably pointless responding to you since you keep repeating the same nonsense over and over. 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] Accessing audio as root
On Mon, 04.01.10 15:10, Bill Cox (waywardg...@gmail.com) wrote: On Mon, Jan 4, 2010 at 2:37 PM, Lennart Poettering lenn...@poettering.net wrote: Also, the sepakup device access should be handled by udev-acl as well. That would probably require non-trivial patching in the speakup tts daemon though. I'm completely ignorant of udev-acl, but if this is the thing that moves around device access rights when you switch users, then I agree. Yes it is. http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/udev-acl/udev-acl.c If we could pass around /dev/soft_synth rights like we do the sound card, we could make this work with user-space code. The critical thing is that /dev/soft_synth rights must always follow the audio card rights. Is it easy to make this work very reliably with CK/udev? Yes, of course. The problem of course is that the tts daemon needs to watch this too and not choke if the device access to that soft_synth device goes away. If this is only a kernel module change, I will sign up to do that. It would be great if we could leave espeakup and speechd-up mostly untouched. This has little to do with the kernel. udev-acl is a userspace code living in udev's tree (see above). 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] Accessing audio as root
On Mon, Jan 4, 2010 at 3:37 PM, Lennart Poettering lenn...@poettering.net wrote: Right. So why not fix orca and make everything work fine in Gnome? I mean, lets fix things properly, not carry on with kludges. I'm guessing you're and Emacs user. What's wrong with Vim? Why don't we simply improve Vim and not carry on with this Emacs kludge? The blind are even more attached to their environment. And speakup isn't a kludge. Real men don't let anyone get in the way of their accessibility, because their jobs depend on it. They write kernel modules to grab console text and slap on an external Braille display, or Dec Talk speech synthesizer. If the rest of the world of software can eventually replace this simple reliable system with something as good, then great, but that day is a long way off. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Mon, 04.01.10 14:21, Bill Cox (waywardg...@gmail.com) wrote: Hi, Lennart. The blind run all sorts of GUI-driven applications like Synaptic, from the System/Administration menu. Howeve, Orca makes these applications accessible when things are working correctly. I agree that we don't want people to login through gdm as root. They do things like su to root and launch Synaptic all the time. It currently works fine. Synaptic is very broken in respect that it runs gtk as root. The gtk developers have made very clear that running gtk code priviliged is evil and should not be done (http://www.gtk.org/setuid.html). As I understood Ubuntu they are now also heading towards usage of packagekit which fixes the gtk-as-root problem and allows fully accessible UIs without horrible security kludges. 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] Accessing audio as root
On Mon, Jan 4, 2010 at 3:48 PM, Lennart Poettering lenn...@poettering.net wrote: The problem of course is that the tts daemon needs to watch this too and not choke if the device access to that soft_synth device goes away. Ok, so I could modify both espeakup and speechd-up to use udev and deal with what happens with /dev/soft_synth rights go away. I can do that. This has little to do with the kernel. udev-acl is a userspace code living in udev's tree (see above). Got it. Thanks Lennart for the tutorial... I'm gonna take back all the things I've said about you (hands you a candy bar)... you've... you've earned it :-) (In case you're not American, that's a Ghost Buster reference). Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Mon, 04.01.10 15:52, Bill Cox (waywardg...@gmail.com) wrote: On Mon, Jan 4, 2010 at 3:37 PM, Lennart Poettering lenn...@poettering.net wrote: Right. So why not fix orca and make everything work fine in Gnome? I mean, lets fix things properly, not carry on with kludges. I'm guessing you're and Emacs user. What's wrong with Vim? Why don't we simply improve Vim and not carry on with this Emacs kludge? The blind are even more attached to their environment. And speakup isn't a kludge. Real men don't let anyone get in the way of their accessibility, because their jobs depend on it. They write kernel modules to grab console text and slap on an external Braille display, or Dec Talk speech synthesizer. If the rest of the world of software can eventually replace this simple reliable system with something as good, then great, but that day is a long way off. You know, this is not how we work, at least in Fedora. We try to fix things properly, we dont like to carry kludges for all eternity. That's why we dropped speakup in Fedora and hope to be able to drop the entire console subsystem eventually. You seem to imply that it is my job to make sure even the oldest or most nichey software is supported properly in PA. Well, that's not the case. If you feel the need to support multiple alternative solutions for the same problem and effectively double your maintainance work you are welcome to do so, but that's your choice, and hence it is *your* job to make things work with it. 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] Accessing audio as root
On Mon, 04.01.10 15:58, Bill Cox (waywardg...@gmail.com) wrote: On Mon, Jan 4, 2010 at 3:48 PM, Lennart Poettering lenn...@poettering.net wrote: The problem of course is that the tts daemon needs to watch this too and not choke if the device access to that soft_synth device goes away. Ok, so I could modify both espeakup and speechd-up to use udev and deal with what happens with /dev/soft_synth rights go away. I can do that. They wouldn't have to link to udev at all. As mentioned they should simply use inotify() and access() to minitor devices access coming and going on /dev/soft_synth. 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] Accessing audio as root
On Mon, 04.01.10 19:56, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Bill Cox at 04/01/10 19:43 did gyre and gimble: Colin and Luke have suggested using CK to deal with this, by killing off speech-dispatcher and speechd-up when the user logs in through gdm, and restarting it when they log out. Note that I wasn't really suggesting that it was killed off per-se. Just that it became a session daemon (like PA is) and that an idle user session was run when the system was idle. This would have the effect of starting it automagically when the system became idle (which implies being at a login prompt) and that it would die off when the system became active (not as a direct result of becomeing active but because the idle session was effectively over/stopped) whereby a users own version of the app could be run instead to take over after they were logged in. That said, Lennart has now clarified how the tty logins are running (tts) and basically that it itself should run a pseudo session jsut like gdm. This seems pretty sensible. Actually if there should really be a proper idle pseudo-session around that shows up in ck-list-sessions is an open question. Instead of having that as proper session we could simply have udev-acl patches mentioned that assigns every device to a particular fallback user if there is no real user active on the seat. The advantage of this more light-weight approach would be that we could easily have different fallback users for different device types and the user would not be confused by the fact that there is this session that never goes away. I have briefly talked to Kay about this, he seems not generally opposed adding either solution, but we're not sure yet which way to follow. 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] Accessing audio as root
On Mon, Jan 4, 2010 at 4:01 PM, Lennart Poettering lenn...@poettering.net wrote: If you feel the need to support multiple alternative solutions for the same problem and effectively double your maintainance work you are welcome to do so, but that's your choice, and hence it is *your* job to make things work with it. In the case of speakup, and a few other key apps for the blind, I can live with that. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Mon, Jan 4, 2010 at 4:03 PM, Lennart Poettering lenn...@poettering.net wrote: They wouldn't have to link to udev at all. As mentioned they should simply use inotify() and access() to minitor devices access coming and going on /dev/soft_synth. Got it. That makes it clearer. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Monday 04 January 2010, Tanu Kaskinen wrote: ma, 2010-01-04 kello 09:37 +, Colin Guthrie kirjoitti: As for the next stage I'm not an expert on this but I think you can try adding: [Element IEC985 Optical Raw] switch = mute switch = mute makes the mixer element state follow pulseaudio's sink mute state, and I don't think you meant to do that. Use switch = off to set the element always off or switch = on to set it always on. Correction printed, thanks. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Kaufman's First Law of Party Physics: Population density is inversely proportional to the square of the distance from the keg. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Lennart Poettering at 04/01/10 20:39 did gyre and gimble: On Mon, 04.01.10 19:36, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Lennart Poettering at 04/01/10 19:06 did gyre and gimble: I agree. and that adding hooks to consolekit (if they don't exist) and the concept of an idle user are probably more practical long term solutions. idle user? By that you mean some pseudo user session that the speakup daemon could be run under? If so, I agree. Yeah, the idea I was generally blundering around was that the idle user was a ck psuedo session that is active when no other session is marked as active - e.g. while sitting at a tty login prompt. I don't know if the getty system could launch a psuedo session itself so that ck doesn't specifically need to be aware of idle status - it was just my way of imagineering how I'd approach the problem which (by the sounds of things) was along the right lines (\o/) getty based logins are currently registered in CK by means of the PAM ckit connector. In the above comment I wasn't meaning the *actual* user login (I know this works fine via the PAM ck stuff) but the login prompt itself (cf the gdm graphical login with it's pseudo session). This was the whole concept of the idle thing I was suggesting and why I was expecting an idle user would be needed to handle this (cf gdm user). Sorry if my (incorrect?) terminology is misleading. We're probably mostly talking about the same thing but I'm just not describing it too well. 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] Accessing audio as root
On Sun, 2010-01-03 at 07:41 -0500, Bill Cox wrote: Hi, Colin. I disagree that speech-dispatcher and speechd-up are broken and need to be fixed. speechd-up is a root daemon attached to the /dev/softsynth device. I see no utility in having multiple copies of it. Speech-dispatcher opens an IP port to act as a speech server over the network. It's kind of a silly feature, but why should I second-guess the speech-dispatchers developers and break it? IMO, what's broken is PA. I can't in Ubuntu get two copies running on the same machine without borking the sound system. If PA can't even do it, why should I mangle all the accessibility apps out there by making them try to follow PA's overly complex model? This has to be a screaming violation of the KISS rule. The sound system is a bit complex. Fine. To use it, you need to make all your apps complex? Really? The complexity has to be contained. It can't keep leaking out of PA into the rest of the system, making it more and more unstable as it goes. Bill IMO from what I've read so far, PA's model is one instance per user. Whether or not its 'overly complex' depends on point-of-view, since this is the same model used by (for example) X11 and jackd. I believe that, in a multi-user system, user-space apps and services should be one instance per user. Of course, I can see how this could be 'overly complex' from a developmental point of view, but its really a matter of the way you view your system. On the other hand, your app (speechd-up) is by its very nature a one instance per system app, as all apps which run as root are (should be?). Not knowing much about how it works, I can just state my belief that it won't be easy to change. So, in my simplistic and user-centric point-of-view, I wonder if speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio sink, with the appropriate modules, of course. It starts before the user logs in and only exits after the user has logged out, of course. The reasoning behind my proposal is simply that root is system-wide by definition (in my understanding), hence why all Colin's proposals have involved speechd-up running as a particular user while all your replies have mentioned root access to pulse ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Bill Cox at 03/01/10 12:41 did gyre and gimble: Hi, Colin. I disagree that speech-dispatcher and speechd-up are broken and need to be fixed. speechd-up is a root daemon attached to the /dev/softsynth device. I see no utility in having multiple copies of it. Speech-dispatcher opens an IP port to act as a speech server over the network. It's kind of a silly feature, but why should I second-guess the speech-dispatchers developers and break it? I think a system service that can convert plain text to speech PCM is a fair enough call, but the bit that actually outputs the sound should very much be a per-user thing. It's a per-user choice whether or not to output this (with a system-wide setting for when the system is idle - on a shared system for both blind and sighted users I'm sure the sighted users accept the need for the speech synthesis at the login stages). If this is a system wide outputer then it needs to have it's own preferences system built in to determin whether or not a given user wants to have the speech enabled or not. I don't think it's right that such apps have to recreate a user preferences system internally or read files in users home directories for preferences (e.g. if a user has an encrypted home dir this could cause some complications). It makes much more sense to run this bit as the user that is running the system. This is a pretty accepted approach I believe. IMO, what's broken is PA. I can't in Ubuntu get two copies running on the same machine without borking the sound system. If PA can't even do it, why should I mangle all the accessibility apps out there by making them try to follow PA's overly complex model? I think this is a problem on your setup and I've seen no evidence yet that it is PA that is at fault here (not ruling it out). I also do not think this model is overly complex. Daniel (the Ubuntu PA guy) has already said that he cannot reproduce this problem and he said he'd like to help you get it working, so I think you should accept his offer and try and work out where the problem is. This has to be a screaming violation of the KISS rule. The sound system is a bit complex. Fine. To use it, you need to make all your apps complex? Really? No. 99.9% of apps run as the user and no additional complexity is needed. This accessibility system is an exception to that rule and as a result does need to be designed properly to fit in with a modern system. The actual approach I've described is actually totally generic and pretty simple when it's boiled down. I've maybe not explained it too well. The complexity has to be contained. It can't keep leaking out of PA into the rest of the system, making it more and more unstable as it goes. To be honest I think this is an overreaction due to you being very involved in this specific use case. I agree is different to what is happening now but even with the current approach there are numerous problems: 1. Different users on the system need their preferences managed by the central app, not via a simple per-user preference scheme common to 99.99% of apps. 2. Encrypted home directories could cause problems. 3. Multi-seat systems could cause problems. 4. Permissions are sub-optimally secure to allow this to work. All in all the approach I describe is much more modern and forward thinking IMO. Yes it needs apps to be updated, but then there are not many apps that are still in use today that are identical to how they were initially written 20 years ago! Everyone has got to move with the times and paradigms. 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] Accessing audio as root
'Twas brillig, and Ng Oon-Ee at 03/01/10 13:26 did gyre and gimble: So, in my simplistic and user-centric point-of-view, I wonder if speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio sink, with the appropriate modules, of course. It starts before the user logs in and only exits after the user has logged out, of course. The reasoning behind my proposal is simply that root is system-wide by definition (in my understanding), hence why all Colin's proposals have involved speechd-up running as a particular user while all your replies have mentioned root access to pulse I guess a possibility is the following: 1. Make console-kit aware of the idle state as before. 2. Make the speechd-up or speech-dispatcher headless. i.e. all they do is open a pipe (fifo) and pump their synthesised speech to it - they do not actually output audio itself. 3. Write a PA module that acts as a pulse client that opens that pipe and outputs the sound (in actual fact, we could use a combination of module-pipe-source and module-loopback for this without writing a single line of code in PA). 4. Place a script in: /usr/lib/ConsoleKit/run-session.d or /etc/ConsoleKit/run-session.d (I'm not sure which is best) which basically does the following (see /usr/bin/start-pulseaudio-x11): /usr/bin/pulseaudio --start --log-target=syslog $@ /usr/bin/pactl load-module module-pipe-source source_name=a11y file=/tmp/a11y.socket /dev/null /usr/bin/pactl load-module module-loopback source=a11y /dev/null (or something like the above - I could have gotten arguments wrong and you may want some channels/rate etc. stuff going on). There may also need to be something setup to stop PA from exiting after an idle timeout. With all that in place things may just work. Obviously speechd-up would have to support multiple clients opening the /tmp/a11y.socket file (and it probably shouldn't actually be in /tmp!). Does that fit better with your model of things? As a side note, would it be wise to provide some kind of positional information along with the raw PCM? I'd have thought that using stereo to good effect may help with a11y? Event sounds are already positional - those triggered at the left of the screen are much louder on the left channel etc. This is just a random thought tho'. 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] Accessing audio as root
Hi, Colin. I like your proposal, but I think I'd like to implement it in two phases. I'd like to skip step 1 for now, and not deal wit CK, but as you say, make speechd-up headless, and write the PA modules you suggest to pipe sound from speechd-up. CK isn't working properly with PA in Ubuntu anyway, and I'd like that to get fixed first, so I can do a Vinux/Ubuntu release based on it. I want to release VInux/Ubuntu Lucid in May, and there's a ton of non-PA related work to do, so for now, I'll stick to what I can get working quickly. Please don't be mad at me if I do one release with PA running as a system daemon. However, for the following release, I'd like to get it right. Speechd-up isn't the only root level sound source that's out there. Espeakup is another alternative to speechd-up which is currently much more popular, but limited in that it can only use the espeak voice. From the point of view of developers for such packages, they just want to write to a sound output interface. Espeakup uses portaudio, and frankly, I don't want to rewrite that interface (one is enough for me). These processes, even speechd-up, set custom buffering parameters in PA (speechd-up requires the tlength paramter to be much shorter than default). Instead of writing modules for PA to talk directly to speechd-up, why not write modules to allow user-land PA instances to read from a special global PA instance? That would simplify life for the root level sound packages greatly, and keep control of the interaction entirely within PA code. What do you think? Also, thanks a ton, Colin, for all the advice! Bill On Sun, Jan 3, 2010 at 9:21 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Ng Oon-Ee at 03/01/10 13:26 did gyre and gimble: So, in my simplistic and user-centric point-of-view, I wonder if speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio sink, with the appropriate modules, of course. It starts before the user logs in and only exits after the user has logged out, of course. The reasoning behind my proposal is simply that root is system-wide by definition (in my understanding), hence why all Colin's proposals have involved speechd-up running as a particular user while all your replies have mentioned root access to pulse I guess a possibility is the following: 1. Make console-kit aware of the idle state as before. 2. Make the speechd-up or speech-dispatcher headless. i.e. all they do is open a pipe (fifo) and pump their synthesised speech to it - they do not actually output audio itself. 3. Write a PA module that acts as a pulse client that opens that pipe and outputs the sound (in actual fact, we could use a combination of module-pipe-source and module-loopback for this without writing a single line of code in PA). 4. Place a script in: /usr/lib/ConsoleKit/run-session.d or /etc/ConsoleKit/run-session.d (I'm not sure which is best) which basically does the following (see /usr/bin/start-pulseaudio-x11): /usr/bin/pulseaudio --start --log-target=syslog $@ /usr/bin/pactl load-module module-pipe-source source_name=a11y file=/tmp/a11y.socket /dev/null /usr/bin/pactl load-module module-loopback source=a11y /dev/null (or something like the above - I could have gotten arguments wrong and you may want some channels/rate etc. stuff going on). There may also need to be something setup to stop PA from exiting after an idle timeout. With all that in place things may just work. Obviously speechd-up would have to support multiple clients opening the /tmp/a11y.socket file (and it probably shouldn't actually be in /tmp!). Does that fit better with your model of things? As a side note, would it be wise to provide some kind of positional information along with the raw PCM? I'd have thought that using stereo to good effect may help with a11y? Event sounds are already positional - those triggered at the left of the screen are much louder on the left channel etc. This is just a random thought tho'. 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] Accessing audio as root
'Twas brillig, and Bill Cox at 03/01/10 16:23 did gyre and gimble: Speechd-up isn't the only root level sound source that's out there. Espeakup is another alternative to speechd-up which is currently much more popular, but limited in that it can only use the espeak voice. From the point of view of developers for such packages, they just want to write to a sound output interface. Espeakup uses portaudio, and frankly, I don't want to rewrite that interface (one is enough for me). These processes, even speechd-up, set custom buffering parameters in PA (speechd-up requires the tlength paramter to be much shorter than default). Well in the situation I'm proposing, the speechd-up would actually just write it's audio to a pipe (totally bypassing pulse client API), and it would be up to module-pipe-source and module-loopback to act as the pulse client, reading from the pipe and actually doing the output. The buffering metrics can be somewhat adjusted when loading module-loopback. Instead of writing modules for PA to talk directly to speechd-up, Well it wouldn't be specific modules, just using module-pipe-source which already exists. It's just a matter of writing to the chosen pipe in a known format. why not write modules to allow user-land PA instances to read from a special global PA instance? That would simplify life for the root level sound packages greatly, and keep control of the interaction entirely within PA code. In principle this is not too bad an idea, but I'm really not sure of the implications of this. I guess some sort of system level PA that is triggered from system dbus or similar could work and still allow the use of some of the PA client libraries. The client would have to specifically ask for access to this and I'm still not sure of the overall security model here. All of the suggestions in this thread are pretty out there anyway and I'd really like to get some feedback from others (especially Lennart) on the most desirable approach. I think he's heading home soon, so should catch up on the backlog in due course! Also, thanks a ton, Colin, for all the advice! I tries me best :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] Accessing audio as root
Hi, On So, Dez 27, 2009 at 01:34:46 +0100, Lennart Poettering wrote: On Sat, 26.12.09 08:31, Halim Sahin (halim.sa...@freenet.de) wrote: Lennart I believe in his particular use-case he's concerned about the screenreader prior to the DE starting up (boot messages and the like?). We actually cover that inside of gdm, where you can get access to the boot messages. Ok what about consolescreenreaders like sbl brltty or speakup? They need a working audiosystem to provide usefull stuff before login or to read the login pprompt. The gdm login screen should be prefectly accessible. I am talking about mixed setups between gdm+gnome and a plain bash textconsole! With pulseaudio I need to login without feedback, start the speech server and then restart the screenreader. Use gdm! Siehe oben. By design mac and windows are not comparable with linux because they are not a multi user OS. That is simply not true. ??? For german users: http://www.stud.uni-hannover.de/stud/unix-ag-bhb/node27.html changing the unix behaviour is the main problem here. Maybe you don't need this but others do. Unix is pretty much a broken system. It might be a useful base and more useful as a base than other systems, but uh, of course we need to deviate from a system that was designed 40 years ago. People who think that Unix is a flawless system and every depature from it would be bad are just incredibly naive. Sorry I want to be able to use my computer (wich isn't possible) if all distros are integrating pulse (like your suggestions). It should be possible to use the audiosystem the (old way). You are always welcome to use a distribution from 3 years ago if you feel that progress is not for you... Thanks a lot for your understanding. I will suggest all blind people to use debian lenny or similar :-(. Read the whole thread and see what happens: All suggestions are producing more complex apps and only pa doesn't need to be changed. Here are my thoughts about pulse: Ok This will my last post in this thread ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sunday 03 January 2010, Ng Oon-Ee wrote: On Sun, 2010-01-03 at 07:41 -0500, Bill Cox wrote: Hi, Colin. I disagree that speech-dispatcher and speechd-up are broken and need to be fixed. speechd-up is a root daemon attached to the /dev/softsynth device. I see no utility in having multiple copies of it. Speech-dispatcher opens an IP port to act as a speech server over the network. It's kind of a silly feature, but why should I second-guess the speech-dispatchers developers and break it? IMO, what's broken is PA. I can't in Ubuntu get two copies running on the same machine without borking the sound system. If PA can't even do it, why should I mangle all the accessibility apps out there by making them try to follow PA's overly complex model? This has to be a screaming violation of the KISS rule. The sound system is a bit complex. Fine. To use it, you need to make all your apps complex? Really? The complexity has to be contained. It can't keep leaking out of PA into the rest of the system, making it more and more unstable as it goes. Bill IMO from what I've read so far, PA's model is one instance per user. Whether or not its 'overly complex' depends on point-of-view, since this is the same model used by (for example) X11 and jackd. I believe that, in a multi-user system, user-space apps and services should be one instance per user. Of course, I can see how this could be 'overly complex' from a developmental point of view, but its really a matter of the way you view your system. On the other hand, your app (speechd-up) is by its very nature a one instance per system app, as all apps which run as root are (should be?). Not knowing much about how it works, I can just state my belief that it won't be easy to change. So, in my simplistic and user-centric point-of-view, I wonder if speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio sink, with the appropriate modules, of course. It starts before the user logs in and only exits after the user has logged out, of course. The reasoning behind my proposal is simply that root is system-wide by definition (in my understanding), hence why all Colin's proposals have involved speechd-up running as a particular user while all your replies have mentioned root access to pulse Regardless, this problem for the visually impaired is one that needs to be addressed ASAP before we have a whole battalion of lawyers from the ACLU challenging us all in courts that we don't, by the very nature of linux, have the funds to defend against. So IMNSHO, it is something that must be done, and damn the reasons for architecting PA the way it currently is. It really is that simple. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) *** *** * ** Confucius say: Is stuffy inside fortune cookie. *** *** ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, Jan 3, 2010 at 12:39 PM, Halim Sahin halim.sa...@freenet.de wrote: Here are my thoughts about pulse: Ok This will my last post in this thread I can put in a good word for Halim. He's been very helpful in the last several weeks working out issues with Orca and the back end sound system. Any good effort to support accessibility needs to include guys like Halim. If Halim is frustrated, that's a bad sign. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
I've removed gdm from my Lucid system, after Tony Sales (founder/driver of Vinux) suggested it. I'm already feeling rather attached to my gdm-less system. It now boots into a very nicely talking console login prompt. I just login, do whatever I like on the console, and type 'startx' if I want Firefox or other graphical applications. I'll make this commitment to the devs of PA: If you support me (I shouldn't require much) in getting Vinux/Ubuntu Lucid working with PA in system-wide daemon mode, I will work hard to make sure the next release is done the right way. Of course, the details of the right way still need to be worked out, given that we need to process speech coming from the /dev/softsynth kernel module. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, 2010-01-03 at 12:29 -0500, Gene Heskett wrote: Regardless, this problem for the visually impaired is one that needs to be addressed ASAP before we have a whole battalion of lawyers from the ACLU challenging us all in courts that we don't, by the very nature of linux, have the funds to defend against. So IMNSHO, it is something that must be done, and damn the reasons for architecting PA the way it currently is. It really is that simple. Maybe I don't have context here, not being from the good ol' USA and all, but is this in any way, shape, or form likely? You know, the whole idea of being sued for the stuff you give away for free not being equal access? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, 2010-01-03 at 13:57 -0500, Bill Cox wrote: I've removed gdm from my Lucid system, after Tony Sales (founder/driver of Vinux) suggested it. I'm already feeling rather attached to my gdm-less system. It now boots into a very nicely talking console login prompt. I just login, do whatever I like on the console, and type 'startx' if I want Firefox or other graphical applications. I'll make this commitment to the devs of PA: If you support me (I shouldn't require much) in getting Vinux/Ubuntu Lucid working with PA in system-wide daemon mode, I will work hard to make sure the next release is done the right way. Of course, the details of the right way still need to be worked out, given that we need to process speech coming from the /dev/softsynth kernel module. In my understanding it really doesn't require much, just copying some key-file somewhere and running pulse with --system. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Gene Heskett at 03/01/10 17:48 did gyre and gimble: And it seem like a doable, sane approach to the problem. A voice of sanity midst the riot this could become. :) But that still leaves PA's biggest problem for this user: It picks the most obviously wrong choice in available audio outputs, whether they exist or not in the hardware (in my case they don't physically exist), and I have not found a way around that yet. A default install of mdv2010 on another drive here is silent, the only thing heard when booting it is the thump in the speakers as udev starts loads emu10k1. I'm a bit confused bu your mail to be honest. Can you explain what you meant a bit about which of your devices it's choosing? Do you have multiple sound cards? pacmd ls output would be good. 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] Accessing audio as root
On Sunday 03 January 2010, Colin Guthrie wrote: 'Twas brillig, and Gene Heskett at 03/01/10 17:48 did gyre and gimble: And it seem like a doable, sane approach to the problem. A voice of sanity midst the riot this could become. :) : But that still leaves PA's biggest problem for this user: It picks the most obviously wrong choice in available audio outputs, whether they exist or not in the hardware (in my case they don't physically exist), and I have not found a way around that yet. A default install of mdv2010 on another drive here is silent, the only thing heard when booting it is the thump in the speakers as udev starts loads emu10k1. I'm a bit confused bu your mail to be honest. Can you explain what you meant a bit about which of your devices it's choosing? Do you have multiple sound cards? Colin, I have posted several times about this, and usually simply ignored. And yesm there are, according to the bus scanning done at bootup, 3 separate audio systems in this machine. 1. There is an intel-hd or whatever its called, claim from my video card that has no connection to the physical world that I can find, on my rv610 chipset based video card. 2. There is another intelhd chipset on the mother board that I suppose might be able to make a few pitiful squeaks should I ever plug any amps speakers into it, and before PA, I was able to dedicate it for use by skype, but not since PA arrived. 3. I have a 24 bit Audigy2 Value with about 64 i/o's that I use for everything because it never runs out of headroom. pacmd ls output would be good. [r...@coyote etc]# pacmd ls E: pacmd.c: No PulseAudio daemon running However, from an lspci -v: 01:07.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value Subsystem: Creative Labs Device 1001 Flags: bus master, medium devsel, latency 32, IRQ 17 I/O ports at 9c00 [size=64] Capabilities: [dc] Power Management version 2 Kernel driver in use: EMU10K1_Audigy Kernel modules: snd-emu10k1 [...] 03:00.1 Audio device: ATI Technologies Inc RV610 audio device [Radeon HD 2400 PRO] Subsystem: Diamond Multimedia Systems Device aa10 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at fddfc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable- Capabilities: [100] Vendor Specific Information ? The motherboard audio system is not found specifically because I build my own kernels (currently running 2.6.32 final) and do not build its driver, therefore simplifying the problem at the expense of losing skype, and that is a shrug, as it's just a toy to annoy verizon with anyway. I do that on general principles anyway. :-) And when booted to mdv2010-x64, PA picks the video card device I've used every pa utility I could find to try and get it away from the 2nd device above and bring some audio back to life, with no apparent effect. Also, booted to mdv-2010-x64, the only place I can see the Audigy card is in lspci and possibly dmesg. PA's tools can't find it. Col I'll reboot and see what I find report shortly. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) For every credibility gap, there is a gullibility fill. -- R. Clopton ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Gene Heskett at 03/01/10 21:48 did gyre and gimble: And yesm there are, according to the bus scanning done at bootup, 3 separate audio systems in this machine. 1. There is an intel-hd or whatever its called, claim from my video card that has no connection to the physical world that I can find, on my rv610 chipset based video card. Presumably an HDMI device. 2. There is another intelhd chipset on the mother board that I suppose might be able to make a few pitiful squeaks should I ever plug any amps speakers into it, and before PA, I was able to dedicate it for use by skype, but not since PA arrived. Strange that this is not possible anymore. You should be able to set an Off profile in pavucontrol's Configuration tab to have pulseaudio ignore any given card and use it for what you like. I presume this is an Intel HDA card. I have a similar card here and it works very well with pulse but the HDA range is really more of a specification than a particular device and there are numerous small variations and a whole bunch of quirks in ALSA to deal with it. Strange that it only has a few squeaks tho'. Is this with Glitch Free mode disabled in draksound? 3. I have a 24 bit Audigy2 Value with about 64 i/o's that I use for everything because it never runs out of headroom. Yeah creative cards can be problematic due to their lack of support for the more advanced way PA drives the hardware. pacmd ls output would be good. [r...@coyote etc]# pacmd ls E: pacmd.c: No PulseAudio daemon running OK, let me clarify: pacmd ls output *while pulseaudio is running* would be good. And when booted to mdv2010-x64, PA picks the video card device I've used every pa utility I could find to try and get it away from the 2nd device above and bring some audio back to life, with no apparent effect. Also, booted to mdv-2010-x64, the only place I can see the Audigy card is in lspci and possibly dmesg. PA's tools can't find it. It should detect the Audigy 2 card even if it doesn't work fantastically in glitch free mode. HDMI cards should be prioritised below PCI cards in the internal priority list so it should never be the default if other cards are detected. The pacmd ls output should be telling. Also, if you can post the pulseaudio - output too that would be useful. Can you start a new thread for this? 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] Accessing audio as root
On Sun, Jan 3, 2010 at 4:48 PM, Gene Heskett gene.hesk...@gmail.com wrote: 01:07.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value Subsystem: Creative Labs Device 1001 Flags: bus master, medium devsel, latency 32, IRQ 17 I/O ports at 9c00 [size=64] Capabilities: [dc] Power Management version 2 Kernel driver in use: EMU10K1_Audigy Kernel modules: snd-emu10k1 If this device isn't audible with speaker-test -Dplug:front:Audigy2 -twav -c2 -l1 (substitute Audigy2 with whatever corresponds from cat /proc/asound/cards), then my guess is that you're experiencing one of the many quirks of the Live and Audigy families where you need to toggle the Analog/Digital Output control. Tritech and Sigmatel both screwed up big time with no way to differentiate between codec revisions that require it to be unmuted (vice those that require it to be *muted*) for audible analog playback. But, as Colin recommended, that would be a separate thread. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sunday 03 January 2010, Ng Oon-Ee wrote: On Sun, 2010-01-03 at 12:29 -0500, Gene Heskett wrote: Regardless, this problem for the visually impaired is one that needs to be addressed ASAP before we have a whole battalion of lawyers from the ACLU challenging us all in courts that we don't, by the very nature of linux, have the funds to defend against. So IMNSHO, it is something that must be done, and damn the reasons for architecting PA the way it currently is. It really is that simple. Maybe I don't have context here, not being from the good ol' USA and all, Since this particular distro is US based, and traded on the NYSE these days... but is this in any way, shape, or form likely? You know, the whole idea of being sued for the stuff you give away for free not being equal access? While I doubt if anybody except the ACLU might get involved, the possibility certainly exists, particularly if a member of that group is adversely effected by this perceived lack. And they are pit bulls when they decide something needs addressing. 'Free' will have nothing to do with it. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Every man is as God made him, ay, and often worse. -- Miguel de Cervantes ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sunday 03 January 2010, Daniel Chen wrote: On Sun, Jan 3, 2010 at 4:48 PM, Gene Heskett gene.hesk...@gmail.com wrote: 01:07.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value Subsystem: Creative Labs Device 1001 Flags: bus master, medium devsel, latency 32, IRQ 17 I/O ports at 9c00 [size=64] Capabilities: [dc] Power Management version 2 Kernel driver in use: EMU10K1_Audigy Kernel modules: snd-emu10k1 If this device isn't audible with speaker-test -Dplug:front:Audigy2 -twav -c2 -l1 (substitute Audigy2 with whatever corresponds from cat /proc/asound/cards), then my guess is that you're experiencing one of the many quirks of the Live and Audigy families where you need to toggle the Analog/Digital Output control. Tritech and Sigmatel both screwed up big time with no way to differentiate between codec revisions that require it to be unmuted (vice those that require it to be *muted*) for audible analog playback. But, as Colin recommended, that would be a separate thread. It should be, I am rebooted to the mdv install at the moment. Anyway I had to make myself root and: [r...@coyote ~]# speaker-test -Dplug:front:Audigy2 -twav -c2 -l1 -bash: speaker-test: command not found [r...@coyote ~]# urpmi speaker-test $MIRRORLIST: media/main/release/speaker-test-1.0.21-1mdv2010.0.x86_64.rpm installing speaker-test-1.0.21-1mdv2010.0.x86_64.rpm from /var/cache/urpmi/rpms Preparing... # 1/1: speaker-test # [r...@coyote ~]# speaker-test -Dplug:front:Audigy2 -twav -c2 -l1 speaker-test 1.0.21 Playback device is plug:front:Audigy2 Stream parameters are 48000Hz, S16_LE, 2 channels WAV file(s) Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 16384 Period size range from 16 to 16384 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384 0 - Front Left 1 - Front Right Time per period = 2.731665 Absolute, total silence. So I found kmix, configured it to include those channels, and I can hear thumps when I mute and unmute the analog channel, but the above command still represents silence, as me or as root. Continuing my beating of this about the brow, I just discovered a channel called IEC985 Optical Raw, brings it to life if its muted. Now the above test works as expected. As either me, or as root. Unforch, some of the pa stuff I apparently need, is missing from the mirrors mandriva uses. So pamon and padev* are not installed. Is there a new method, or do I go fuss at the mdv people? Next? Thanks Daniel. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) One Bell System - it works. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, Jan 03, 2010 at 01:08:07AM EST, Colin Guthrie wrote: 'Twas brillig, and Tanu Kaskinen at 02/01/10 05:59 did gyre and gimble: So that's how I see it should work. I'm not very confident when speaking about consolekit and boot/login processes, so I have to hope that the system I described isn't too different from how things work in reality. I think I agree more or less, but with perhaps a few caveats/clarifications. 1. I think the anybody user is a valid concept. I'd personally call it the idle or inactive user as homage to the active denomination in consolekit already. To run some practical tests, if you run: [co...@jimmy ~]$ ck-list-sessions Session1: unix-user = '603' realname = 'Colin Guthrie' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-12-30T09:40:14.334448Z' login-session-id = '4294967295' you can see that I am the active user currently. If however I run the following and then switch to the login window on tty1: [co...@jimmy ~]$ sleep 3; ck-list-sessions Session1: unix-user = '603' realname = 'Colin Guthrie' seat = 'Seat1' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-12-30T09:40:14.334448Z' login-session-id = '4294967295' Here we see that no user is currently active. In this mode no user is active on my system - i.e. it's idle. Now lets think about permissions. Some folks have recently mentioned the audio group. This is a relic and should not be used or considered for controlling access to audio hardware. The real way forward is the interaction between udev and console kit applying ACLs for the appropriate users. Now in this case we really need to define a user on the system who is idle. Both udev and console-kit probably need to be aware of this concept and write the appropriate ACLs to the sound hardware for the idle user, removing them when a real user logs in (and in this case gdm should be considered a real user. This sounds good, however one big problem is that speakup is actually kernel code, i.e its run as a kernel module, so it can get low level access to the tty devices to read the text. For the record, I am a vision impaired user, who uses a screen reader, and again for the record, this is an approach I am personally very much against. Instead, we need a daemon that will run as the idle user, and then through the hand-over stuff discussed in the rest of Colin's email, act appropriately. There are already user-space device nodes for reading the contents of the tty, and the BrlTTY Braille display daemon already uses these. BrlTTY already supports speech output, so it needs screen reader control via keyboard added, as well as working accross multiple user sessions etc. In short, what has happened here, is that the Linux desktop has evolved, and the accessibility software for people with blindness/vision impairement, has not. If such software wants to stay relevant, it has to evolve, or it will die. So yes we need consolekit to have idle user support, and then we need all the lower level accessibility software, eg for using Braille displays/speech output for the console, to also be improved to work system wide, and per user. I would be happy to do this work, if I had the time. :) Luke ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Tanu Kaskinen at 02/01/10 05:59 did gyre and gimble: So that's how I see it should work. I'm not very confident when speaking about consolekit and boot/login processes, so I have to hope that the system I described isn't too different from how things work in reality. I think I agree more or less, but with perhaps a few caveats/clarifications. 1. I think the anybody user is a valid concept. I'd personally call it the idle or inactive user as homage to the active denomination in consolekit already. To run some practical tests, if you run: [co...@jimmy ~]$ ck-list-sessions Session1: unix-user = '603' realname = 'Colin Guthrie' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-12-30T09:40:14.334448Z' login-session-id = '4294967295' you can see that I am the active user currently. If however I run the following and then switch to the login window on tty1: [co...@jimmy ~]$ sleep 3; ck-list-sessions Session1: unix-user = '603' realname = 'Colin Guthrie' seat = 'Seat1' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-12-30T09:40:14.334448Z' login-session-id = '4294967295' Here we see that no user is currently active. In this mode no user is active on my system - i.e. it's idle. Now lets think about permissions. Some folks have recently mentioned the audio group. This is a relic and should not be used or considered for controlling access to audio hardware. The real way forward is the interaction between udev and console kit applying ACLs for the appropriate users. Now in this case we really need to define a user on the system who is idle. Both udev and console-kit probably need to be aware of this concept and write the appropriate ACLs to the sound hardware for the idle user, removing them when a real user logs in (and in this case gdm should be considered a real user. In this case the boot scenario (permissions wise) would be as follows: 1. Turn on (this will rarely change and I predict will remain the first step for many years :p) 2. udev kicks in. 3. system dbus starts 4. consolekit starts and due to no active users instructs udev to write the idle user to the audio device node ACLs (I'm not 100% sure whether udev drives console-kit or the other way round, so someone more familiar than me with this can hopefully clarify) 5. Some special handling in the boot process will launch speakupd as the idle user (I think this is appropriate - there should not (IMO) be a central daemon for sepakupd - it should be launched when needed). I'm not specifically sure if it is the boot up process per-se or the system becomes idle case that really should be responsible for starting speakupd... My gut feeling is that console-kit should be aware of idle status and have a set of hooks that can be run when this happens. These hooks could then be used to start speakupd as the idle user). At this stage the idle user can now start talking about what is going on with the boot. 6. X is launched and GDM (or equiv) is started, console-kit will now realise there is an active session started for the gdm user and remove the ACLs on the sound device. The idle user's speakupd can die as can it's PA instance. GDM user will start it's own speakupd and PA process. 7. If at this stage the user logs in graphically then the same thing as idle-gdm happens. The gdm user's PA and speakupd process dies and the real user's one will kick in. 7b. Now if the user switches to tty1 (whether at gdm login screen or after logging in - the concept is the same), console-kit will notice the system has become idle and apply the appropriate ACLs, due the idle hooks mentioned in 5 above, speakupd/PA will be launched and the login prompt can be described audibly. Once logging in the user becomes active again, so the idle user is killed off as before and can hand over to the real user. Thinking about it, I think that consolekit itself is really what should be responsible for starting speakupd (which will in turn start pulseaudio if appropriate). I think that some kind of system becomes idle and user becomes active hooks would provide the necessary framework into which speakupd could integrate. The concepts of starting a service are starting to erode these days with more and more things being triggered from udev, so the general migration to this approach (i.e. making speakupd serviceless) seems to be followed with the above suggestion too. Also on a system shared by both blind and sighted users there does not need to be any special support for detecting the current user and either giving prompts or not. If
Re: [pulseaudio-discuss] Accessing audio as root
Hi, Col. I'm willing to try the aproach you suggest, but I'd like to debate the implementation some more. If I understand correctly, I can use CK to determine whenever the sound card permissions are moved to a new user (which is basically whenever a user takes over the seat, except as root), and can then launch the various accessibility apps the user needs as that user. Is this basically correct? Since there are several apps that are candidates, I'm tempted to allow them to be listed in some /etc config file, rather than duplicating the code for each. That would provide users a mechanism for having apps follow the sound card. Should I make this a PA capability with a PA module? If I made this a PA module, and if I'm basically trying to kill client apps when PA loses a sound card, and launch client apps when it gains a sound card, then might it make sense to add a hook within PA to do this, and not deal with CK? Probably because I've read some PA code, and not CK, I'm thinking it would be easier and more robust. Why do I need to have an idle hook? It sounded good when I read it the first time, but now I'm confused. Thanks, Bill On Sat, Jan 2, 2010 at 11:52 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Bill Cox at 02/01/10 15:03 did gyre and gimble: Hi, David. On Sat, Jan 2, 2010 at 1:08 AM, David Henningsson launchpad@epost.diwic.se wrote: I was just thinking, and this idea is perhaps not 100% thought through, but it could be worth considering. We have this hand-over mechanism: http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt You obviously know more about the plumbing than I do! I don't know anything about d-bus, so my opinion counts little, but it looks like a good direction to me. I would want to bury all the complexity of dealing with d-bus under the pulse-simple API, so that only a one-line change has to be made to clients like speakup/espeakup and speakup/speechd-up. I'm not quite sure how this works. When a speakup client wants access to the sound card, it could request access at high priority, and then plays it's sound. How would it hand back the sound card to the other user and uncork it? If this were automatic once the queue was empty for say one second, that would be great. Is this the sort of thing we can do with PA/CK? While this would theoretically work, I think it's probably not needed. The reservation system is really meant for interacting with jack and while it's not exclusive, I think it's not really an appropriate technique to solve this problem. I think the general concept of the speech dispatchers running as a system service is the bit that needs re-thought and that adding hooks to consolekit (if they don't exist) and the concept of an idle user are probably more practical long term solutions. Of course I could be wrong on that front :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] Accessing audio as root
This scheme sounds reasonable, though whenever someone says impossible, I'm naturally inclined to give it a solid try. Why would it be impossible to add PA hooks I could run when PA gains, uncorks, corks, or delets a connection to a card? I thought I already saw a system of hooks being called. I'm worried that if I follow the user instead using CK, and my logic for card access transfer does not match PA's, then I might transfer speach while PA does not transfer audio card access. We have to kill the user's speech-dispatcher and speechd-up deamons when access to a card is transfered to a new PA instance. There can only be one speechd-up and one speech-dispatcher process at a time. For one think, speechd-up locks the /dev/softsynth device, and the second speechd-up wont even run. speech-dispatcher opens a port, which speechd-up uses for communication, and multiple speech-dispatchers conflict on the port. But, it should not be a problem restarting these deamons as needed. If the audio card leaves, there's no reason to have these processes hanging around. Bill On Sat, Jan 2, 2010 at 4:47 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Bill Cox at 02/01/10 21:03 did gyre and gimble: Hi, Col. I'm willing to try the aproach you suggest, but I'd like to debate the implementation some more. If I understand correctly, I can use CK to determine whenever the sound card permissions are moved to a new user (which is basically whenever a user takes over the seat, except as root), and can then launch the various accessibility apps the user needs as that user. Is this basically correct? Since there are several apps that are candidates, I'm tempted to allow them to be listed in some /etc config file, rather than duplicating the code for each. That would provide users a mechanism for having apps follow the sound card. Should I make this a PA capability with a PA module? Right in principle but not quite what I was suggesting in practice. Essentially I am suggesting that console kit is altered to have a set of hooks that it itself runs. Your system will be running the console-kit-daemon and it already has folders like: /usr/lib/ConsoleKit/run-session.d Which is run when a new user logs in. What I am suggesting is to add the concept of the idle session and a system idle user. If I made this a PA module, and if I'm basically trying to kill client apps when PA loses a sound card, and launch client apps when it gains a sound card, then might it make sense to add a hook within PA to do this, and not deal with CK? No, this is totally impossible - remember that there are multiple PA processes, one for each user. The above suggestion would only work if there was a single PA daemon for all users. This is why I think console-kit is the correct place to do this - there is a single system-wide daemon running here and it already has a hooks system. PA clients should never be killed - they will just be corked if the user becomes inactive and uncorked when they become active again. Probably because I've read some PA code, and not CK, I'm thinking it would be easier and more robust. Sadly this is the wrong concept and not what I've actually been suggesting. I'd recommend you read up on console-kit a bit and perhaps speak to some of their devs about it and see whether what I'm suggesting is sensible or not. Why do I need to have an idle hook? It sounded good when I read it the first time, but now I'm confused. This is the key thing about what I'm suggesting. When you switch to the login prompt on tty1, there is no active user but yet you still want the prompt to be read out and have sound. For this I suggest adding the concept of an idle system. This should be the same as the gdm login screen really but it runs a real (albeit psuedo) session under the gdm user. The same is not true for tty logins which is why I think an idle user should take this job. It may or may not make sense for gdm to be run as the idle user too rather than it's own dedicated user. Anyway when the system becomes idle (e.g. tty1 prompt) this basically means no user is active and implies either a status screen or a login prompt. When the user becomes idle the hooks installed to consolekit by the speechd-up package will cause the speechd-up daemon to be run. This daemon will then be able to speak the login prompt. When the user logs in, console-kit will be informed about this and the idle session will be killed (or suspended) and then the user's own session will be start. The hooks for user logs in in consolekit can then start a speechd-up process for that user if it's not already running (if it's running already from a graphical session and the user switches to tty1 and logs in the speechd-up already running from the graphicial login will just be reused). This is very much the same principle as pulseaudio itself (e.g. one PA process runs for a given user even
Re: [pulseaudio-discuss] Accessing audio as root
I spent a few hours trying to figure out how well this scheme could work for Ubuntu/Lucid. Things are in bad shape. Speakup basically is incompatible with PA on Lucid for now. The problems seem to come from multiple PA instances not sharing properly. If you switch-user to a new user on Karmic or Lucid, the new user has no access to the sound card. With the gdm PA instance running inorder to speak console login prompts, and the user PA running in Gnome, I can't get both to work at the same time. Since I'm not aware of any time that this has ever worked properly on Ubuntu with PA, I suspect it may be years before these issues are fixed. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
Sorry... my laptop has a tendency to accidentally click, and I sent that last e-mail unfinished. Anyway, I don't believe I've evern seen multiple copies of PA running in Ubuntu work properly together, and the open bug about this on bugs.launchpad.net has had no progress or interest. If I write the CK code to kill speech-dispatcher and relaunch it when we switch user, it wont work in Ubuntu. IMO, the prudent thing to do for the Lucid release is guide blind users to be sure they only have one PA instance at a time. In particular, I'm thinking of requiring that they log in through gdm before switching to a console (for the non-CLI version). We can add speechd-up as a startup application to be automatically launched after speech-dispatcher and Orca. When I do this in Karmic, the consoles have good speakup performance. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
(Answer to both Colin and Bill) Colin Guthrie wrote: 'Twas brillig, and Bill Cox at 02/01/10 15:03 did gyre and gimble: Hi, David. On Sat, Jan 2, 2010 at 1:08 AM, David Henningsson launchpad@epost.diwic.se wrote: I was just thinking, and this idea is perhaps not 100% thought through, but it could be worth considering. We have this hand-over mechanism: http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt You obviously know more about the plumbing than I do! I don't know anything about d-bus, so my opinion counts little, but it looks like a good direction to me. I would want to bury all the complexity of dealing with d-bus under the pulse-simple API, so that only a one-line change has to be made to clients like speakup/espeakup and speakup/speechd-up. You're talking about the pulse-simple API here, I thought the speech daemon, timidity etc were using ALSA directly? Are you planning to change that? (And if you do, what consequences will that bring to speakup being able to talk when PulseAudio is down?) I'm not quite sure how this works. When a speakup client wants access to the sound card, it could request access at high priority, and then plays it's sound. How would it hand back the sound card to the other user and uncork it? Good question. I'm assuming it is handled in a good way already between PulseAudio and Jack and that way could work here as well. I think one can listen to org.freedesktop.DBus.NameOwnerChanged, or just poll once a second. However the reserve API does not currently handle (in the best way) if there is more than one client waiting for the soundcard. If this were automatic once the queue was empty for say one second, that would be great. Is this the sort of thing we can do with PA/CK? While this would theoretically work, I think it's probably not needed. The reservation system is really meant for interacting with jack and while it's not exclusive, I think it's not really an appropriate technique to solve this problem. I think the general concept of the speech dispatchers running as a system service is the bit that needs re-thought and that adding hooks to consolekit (if they don't exist) and the concept of an idle user are probably more practical long term solutions. Of course I could be wrong on that front :p Taking it a step back, and looking at it from a higher, conceptual level, I think it depends on how you view upon the soundcard. If you view it as a part of the seat (as in ConsoleKit's definition), then the ConsoleKit approach makes most sense. If you view the soundcard as a system-wide resource, it makes more sense to make the reserve API system-wide as well. PulseAudio has taken the seat approach, whereas the speak server has taken the system-wide resource approach. And I personally think both views are equally valid - after all, we don't know anything about the actual physical location of the speakers/mic! So for PulseAudio to be a little friendly in a heterogeneous world, would it hurt to move/copy the reserve API to the system d-bus? Then it would be up to the speech daemon, timidity, and the others, to make their own choice whether they want to integrate with ConsoleKit and get the mixing features of PulseAudio, or - a little more quick and dirty, perhaps - just request the device on the d-bus. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 17, 2009 at 4:52 AM, Lennart Poettering lenn...@poettering.net wrote: I don't see why anyone would want to have audio when changing to root for admin purposes. Playing music certainly does not fall under admin purposes. Ever consider what happens when a blind user switches to root, and his sound card stop speaking? This is no hypothetical situation, like someone trying to spy on me through Alsa by taking over my mike. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 6:57 AM, Lennart Poettering lenn...@poettering.net wrote: And this is the problem because it works with alsa, simply add every user you want to give audio access to the audio group and it worked. Even with OSS this worked. But PA breaks this behaviour. First of all, we broke exactly nothing. You can always bypass PA and do stuff like this. Secondly, allowing access to the audio device to all users is a security hole as I tried to explain quite a few times. Allowing that means a user can evesdrop into your voip calls, he can even completely monitor whatever you say when you sit in front of your computer. How can I bypass PA on a Ubuntu Karmic or Lucid? If I disable user-land pulseaudio, several applications break, including the volume control. PulseAudio has been Vulcan mind-melded into the system. If you know of a realistic way to bypass PulseAudio, by all means, please state it! If sound were just for music, this wouldn't be a big deal. Speakup needs to route speech to the sound card, regardless of who is logged in, and in parallel with whatever music or speech they are playing. PulseAudio has broken Linux accesibility for the blind quite seriously. I'm a C coder, willing to help. Got any ideas for a solution? Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 9:13 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Halim Sahin at 23/12/09 13:24 did gyre and gimble: The Problem can be summarized in one sentence: Pulseaudio currently breaks multiuser systems and is only useful for one-user-desktop. Actually no, the exact opposite. PA works very well for multi user desktops. Hi, Col. Let me say I'm beginning to be a fan of your posts, as I read more of them. This is probably an Ubuntu issue, but in Karmic and Lucid, Switch User does not change the permissions for the sound card, and the new user will be mute. It's a fairly minor bug... the work-around is logout and log back in. IMO, Halim's more important comment was that PulseAudio breaks accessibility. Speakup is either the #1 or #2 most popular Linux accessibility program for the blind and visually impaired. It starts at boot, as it should, so a blind person can hear what's going on. Gdm kills PulseAudio when a user logs in. Speakup runs forever, and it' PulseAudio process hangs around forever, locking up the sound card, so the user can't get any sound in Gnome. I'm not a bad C coder. I can patch this and make it work. But I don't want to go writing a random work-around blindly! I need advice as what the right solution is. Here's one thought, but I haven't examined the code effected. What if we allow certain users parallel access to particular sound card? Speakup launches speechd-up which launches speech-dispatcher during boot, as user 'speech-dispatcher'. If speech-dispatcher ran as gdm instead, and we allowed gdm to always access the sound card? That way, gdm would reuse speech-dispatcher's copy of pulseaudio rather than making a new one, and we'd no longer have to worry about killing gdm's copy of pulseaudio when a user logs in, or restarting it when he logs out. Is that the best way to patch this system? Thanks, Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 11:14 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: I think it's pretty clear what the problem is. PA does not support multiple users on one system.. I told you if you intend to replace the existing audio system and build up compatibility layers add try to do it right. But for you right === the exact same way it used to work. Hi, Colin. I think it is important to understand where people like Markus come from. I suspect he's completely blind. Right for him means his system talks to him at boot, in both speakup and Orca and probably a few other apps. Wrong is when the sound system stops speakup or Orca from talking. It's the ultimate show-stopper bug for the blind. Losing sound for a blind person is about as scary as a hard-disk crash - maybe worse! A blind person often has to track down a sighted person with the skills to repair his software in person. This can be a lot harder than installing a new hard drive and OS. I want to help constructively. I want to track down the problem and suggest a patch. Any guidance as to the approach to take would be very welcome - I really don't know the PulseAudio system well enough to determine the best approach. Eventually, I'll just pick one and do it, but it's worth begging for advice if I can get it! Thanks, Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 11:29 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 23.12.09 15:26, Halim Sahin (halim.sa...@freenet.de) wrote: Hi Col, 1. I gave you some examples what doesn't work as expected. How should I run my text-to-speech server before login to have audiooutput for reading the login screen? On Fedora at least the screenreader runs as normal process in the gdm pseudo-session which also happens to run a PA instance. So everything should be fine here, and I am quite sure this is not only done on Fedora this way but all other distributions that use a current version of gdm. Lennart, let me explain how blind people use Linux. There are TWO applications in common use - Orca and Speakup. Actually, there's a third - emacspeak, but let's not go there, yet. Orca is the screen reader that you are talking about. It runs as user, and can be made to work well with PulseAudio. I've personally helped in that effort (I wrote a new pulseaudio driver for it). The other critical application is Speakup. It runs as a kernel module and speaks every bit of console output during the boot process. Many blind people rely heavily on Speakup, and only use Orca for websites that require Firefox to read. 2. Running daemons worked well under alsa (see my previous post). I am using every day this setup. Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and as such everything you could do with ALSA before stays available with PA too. However input output deamons should definitely be part of the user session. That is true for PA itself AND any kind of speech daemon and suchlike. Output deamons do belong in the user session, but not all speech deamons do. Speakup, in particular, is a kernel module. It's job is speaking all console output to the user. The blind don't give a hoot how we get speach from /dev/speakup_soft to the sound card. It just has to happen. Today, on every pulseaudio enabled system I know of, this does not work properly. I tried setting speakup to use alsa, and it works, right up until pulseaudio for gdm starts. After that, speakup is mute. Is there any way for pulseaudio to share the sound card with speakup/alsa? Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 12:27 PM, Lennart Poettering lenn...@poettering.net wrote: We actually cover that inside of gdm, where you can get access to the boot messages. Lennart Speakup doesn't stop reading when the user logs into Gnome. When we type Ctrl+Alt+F1, we get a console screen which is read by speakup. It reads the login prompt, and then all the console text after login, whether as a normal user, or as root. It runs in parallel with Gnome, and never exits until shutdown. Most blind Linux users I know love this behaviour, and will not consider Linux distros that don't support it. This is why web sites like this recoment removing PulseAudio from Ubuntu: http://live.gnome.org/Orca/UbuntuKarmic This is why Ubuntu disables PulseAudio if the user selects an accessible install. I would like to help Ubuntu keep PulseAudio even with an accessible install. Any right solution should require little and probably zero changes to programs like speakup. We should be able to tell the sound system that speakup is allowed to share the sound card with PA. Speakup already has both pulseaudio and alsa drivers, and if we can get either working with PA in parallel, we're in good shape. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Fri, 2010-01-01 at 23:29 -0500, Bill Cox wrote: On Thu, Dec 24, 2009 at 11:14 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: I think it's pretty clear what the problem is. PA does not support multiple users on one system.. I told you if you intend to replace the existing audio system and build up compatibility layers add try to do it right. But for you right === the exact same way it used to work. Hi, Colin. I think it is important to understand where people like Markus come from. I suspect he's completely blind. Sorry, I'm pretty sure from previous mails from Markus that his main issue is a certain hardware his company sells which requires root to be able to access pulseaudio, some TV-sort thingy. He's mentioned this repeatedly in the months I've been on this list. Sorry I can't help more with your issue, I've been reading the conversations about it and think you have a point, but it'll be quite a bit of work to get things working. It may perhaps be better to use alsa with dmix as markus has suggested. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
pe, 2010-01-01 kello 23:13 -0500, Bill Cox kirjoitti: IMO, Halim's more important comment was that PulseAudio breaks accessibility. Speakup is either the #1 or #2 most popular Linux accessibility program for the blind and visually impaired. It starts at boot, as it should, so a blind person can hear what's going on. Gdm kills PulseAudio when a user logs in. Speakup runs forever, and it' PulseAudio process hangs around forever, locking up the sound card, so the user can't get any sound in Gnome. If speakup's model is that the daemon runs forever, without changing the user when sessions are switched, it's in conflict with the normal pulseaudio model, ie. the currently active user owns the sound hardware. If the two programs are to be used simultaneously, one of these two models has to change. Pulseaudio's model can be changed by running it in system wide mode. That's a viable solution, but not ideal for the known reasons. Another approach, which you seem to have started thinking about, is modifying pulseaudio's normal operating model so that it's compatible with speakup. This approach should be used if speakup's current model is correct. Otherwise speakup should be modified. My personal opinion is that speakup's model is not correct, but since I'm not going to do any coding related to this anyway, my opinion is irrelevant. But here's how I see speakup should work, judge for yourself if it makes any sense: At boot --- At boot time there isn't really anybody having a private session; the boot messages are public. Speakup should run as user anybody (that's just a placeholder), and this anybody user has his own pulseaudio daemon running. Then either gdm or a console login manager starts. In my opinion, they should also run as anybody, but there are probably reasons why gdm runs as user gdm. That's why I use anybody just as a placeholder - speakup may also have to use a custom user. At login After logging in, the current session has become private to the logged in user. The pulseaudio daemon that the login manager used releases the sound card, and a new pulseaudio daemon is launched for the user. Now speakup has to start to use the user's pulseaudio. This happens by starting a new speakup daemon instance as part of the user's session setup. Regarding this handover, it may need more or less logic in speakup - I don't know how speakup works. If only one daemon can use /dev/speakup_soft at a time, the previous instance needs to use consolekit to know when to release the access to /dev/speakup_soft and acquire it again when its session becomes active. The pulseaudio daemon of the anybody user stays running, streams to the sound card are just suspended. Speakup should probably detect this and close the stream when the session is deactivated, because when the session is activated again, I suspect you don't want to continue speaking from where you left off. Switching virtual terminals --- Switching virtual terminals works similarly to the login case. The access to the sound card moves from one user to another (might be anybody - in theory it doesn't make any difference whether the terminals have someone actually logged in or if the terminal user is the anybody dummy user). So that's how I see it should work. I'm not very confident when speaking about consolekit and boot/login processes, so I have to hope that the system I described isn't too different from how things work in reality. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
Bill Cox wrote: On Thu, Dec 24, 2009 at 12:27 PM, Lennart Poettering lenn...@poettering.net wrote: We actually cover that inside of gdm, where you can get access to the boot messages. Lennart Speakup doesn't stop reading when the user logs into Gnome. When we type Ctrl+Alt+F1, we get a console screen which is read by speakup. It reads the login prompt, and then all the console text after login, whether as a normal user, or as root. It runs in parallel with Gnome, and never exits until shutdown. Most blind Linux users I know love this behaviour, and will not consider Linux distros that don't support it. I was just thinking, and this idea is perhaps not 100% thought through, but it could be worth considering. We have this hand-over mechanism: http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt It looks nice, except for that it lives on the session D-bus. Now assume we move (or copy) it to the system D-bus instead. Then we implement the handover request in speakup, timidity, and other programs not running inside the session context. This seems like a working middle-way between using the user's PulseAudio (which seems difficult, especially when it changes) and the path of uninstalling PulseAudio completely. I'm not a qualified plumber, so I could possibly be missing something obvious here. What do you think? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sat, 26.12.09 18:03, Ng Oon-Ee (ngoo...@gmail.com) wrote: I've been following these discussions with some (layman-level, I don't dev for pulse) interest, and I'm wondering whether a simple solution would be to use alsa-output prior to login and pulseaudio after login. A bit of configuration required instead of re-writing apps. Something would have to be done to get the screen reader to not hog the hw when the user is logged in, that shouldn't be too difficult though. Yes, this is actually what I suggested a couple of times: it is possible to bypass PA, which is useful if you want to do audio outside of any session. 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] Accessing audio as root
On Sat, 2009-12-26 at 08:31 +0100, Halim Sahin wrote: Hi, On Do, Dez 24, 2009 at 06:27:25 +0100, Lennart Poettering wrote: On Fri, 25.12.09 00:47, Ng Oon-Ee (ngoo...@gmail.com) wrote: Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and as such everything you could do with ALSA before stays available with PA too. However input output deamons should definitely be part of the user session. That is true for PA itself AND any kind of speech daemon and suchlike. Lennart I believe in his particular use-case he's concerned about the screenreader prior to the DE starting up (boot messages and the like?). We actually cover that inside of gdm, where you can get access to the boot messages. Ok what about consolescreenreaders like sbl brltty or speakup? They need a working audiosystem to provide usefull stuff before login or to read the login pprompt. With pulseaudio I need to login without feedback, start the speech server and then restart the screenreader. sorry folks I seems that you can't sink of usecases other than yours. Facts are: You have developed a new audio system which brings more flexibility and features to us. Unfortunately you expect that all projects should rewrite their audio stuff to work with your system. By design mac and windows are not comparable with linux because they are not a multi user OS. For german users: http://www.stud.uni-hannover.de/stud/unix-ag-bhb/node27.html changing the unix behaviour is the main problem here. Maybe you don't need this but others do. It should be possible to use the audiosystem the (old way). Just my 2 cents. Halim I've been following these discussions with some (layman-level, I don't dev for pulse) interest, and I'm wondering whether a simple solution would be to use alsa-output prior to login and pulseaudio after login. A bit of configuration required instead of re-writing apps. Something would have to be done to get the screen reader to not hog the hw when the user is logged in, that shouldn't be too difficult though. I must admit its good to hear of an actual use-case where such behaviour is useful, instead of some of the random complaining that comes here seasonally. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
Hi, On Do, Dez 24, 2009 at 06:27:25 +0100, Lennart Poettering wrote: On Fri, 25.12.09 00:47, Ng Oon-Ee (ngoo...@gmail.com) wrote: Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and as such everything you could do with ALSA before stays available with PA too. However input output deamons should definitely be part of the user session. That is true for PA itself AND any kind of speech daemon and suchlike. Lennart I believe in his particular use-case he's concerned about the screenreader prior to the DE starting up (boot messages and the like?). We actually cover that inside of gdm, where you can get access to the boot messages. Ok what about consolescreenreaders like sbl brltty or speakup? They need a working audiosystem to provide usefull stuff before login or to read the login pprompt. With pulseaudio I need to login without feedback, start the speech server and then restart the screenreader. sorry folks I seems that you can't sink of usecases other than yours. Facts are: You have developed a new audio system which brings more flexibility and features to us. Unfortunately you expect that all projects should rewrite their audio stuff to work with your system. By design mac and windows are not comparable with linux because they are not a multi user OS. For german users: http://www.stud.uni-hannover.de/stud/unix-ag-bhb/node27.html changing the unix behaviour is the main problem here. Maybe you don't need this but others do. It should be possible to use the audiosystem the (old way). Just my 2 cents. Halim ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Halim Sahin at 23/12/09 14:26 did gyre and gimble: Hi Col, 1. I gave you some examples what doesn't work as expected. How should I run my text-to-speech server before login to have audiooutput for reading the login screen? GDM runs under the gdm user and starts it's own PulseAudio process. This can be easily used to do the reading of the login screen. I'm not familiar with how screen readers work but that software should also be launched as the gdm user. When a real user logs in, gdm's PA and screenreader services will die or be suspended and the real user's PA and screenreader service takes over. 2. Running daemons worked well under alsa (see my previous post). I am using every day this setup. Speechd runs with uid speech-dispatcher and I can also play sound as user halim. I don't see any reason why speech-dispatcher needs to run as it's own user. Why not just run it as the user who is actually using it? At the end of the day the fact that a uid speech-dispatcher can access a users' sound is disturbing. If that user is compromised they can evesdrop on your user which is not very nice. But it introduced problems wich should be fixed. I agree it has introduced problems for certain applications but just because something has changed, it doesn't mean that PA needs to support an obsolete, weird or insecure way of working that was permitted in the past. Your given examples are related to x-sessions. Go one step back. gdm starts and the screenreader-speech-server (before login). If pulseaudio starts at this time, it would use gdm uid. This is indeed what happens. In this case the audiocard can't be used by another pulseaudio after successful login. Yes it can. After login the gdm user is no longer permitted access to the audio devices and the logging in user take over control, starts their own PA etc. It all works nicely. Hope this helps. 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] Accessing audio as root
'Twas brillig, and Markus Rechberger at 23/12/09 14:35 did gyre and gimble: On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. Can you give links to these bug reports please? read up my use case and read up Halim's use case, have a look at freshmeat.net how many projects are broken because of pulseaudio. My advice is to make your way optional, add a configuration option which provides a compatibility mode. You want to improve audio with linux? then please do so. You guys spent alot time on everything already and something like that should not be a showstopper. So no actual bug reports then? 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] Accessing audio as root
On Thu, Dec 24, 2009 at 1:29 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 23/12/09 14:35 did gyre and gimble: On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. Can you give links to these bug reports please? read up my use case and read up Halim's use case, have a look at freshmeat.net how many projects are broken because of pulseaudio. My advice is to make your way optional, add a configuration option which provides a compatibility mode. You want to improve audio with linux? then please do so. You guys spent alot time on everything already and something like that should not be a showstopper. So no actual bug reports then? Heh. I think the issue is resolved. apt-get remove pulseaudio is the preferred way to get audio work again. I don't see the reason why someone should use a faulty audio system. Alsa is working well enough for most applications, for the rest Windows and OSX have to be used. Merry Christmas, Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 24/12/09 12:43 did gyre and gimble: On Thu, Dec 24, 2009 at 1:29 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 23/12/09 14:35 did gyre and gimble: On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. Can you give links to these bug reports please? read up my use case and read up Halim's use case, have a look at freshmeat.net how many projects are broken because of pulseaudio. My advice is to make your way optional, add a configuration option which provides a compatibility mode. You want to improve audio with linux? then please do so. You guys spent alot time on everything already and something like that should not be a showstopper. So no actual bug reports then? Heh. I think the issue is resolved. apt-get remove pulseaudio is the preferred way to get audio work again. I don't see the reason why someone should use a faulty audio system. Alsa is working well enough for most applications, for the rest Windows and OSX have to be used. Haha, sure whatever works for you. All I'm saying is do you expect us to trawl the internet and dig up problems without any kind of technical detail or debug info attached to them or do you think we should concentrate on answering and dealing with problems in a prescribed and constructive way - e.g. via our BTS. Honestly, give us solid bug reports and we'll attempt to fix the problems reported, but don't come here spreading FUD and talking bullshit throwing accusations without backing them up with anything other than heresay. What I want for Christmas is BUG REPORTS with proper debug information and trigger cases. Don't report a bug, don't see a fix... shock of the decade. 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] Accessing audio as root
On Thu, Dec 24, 2009 at 2:50 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 24/12/09 12:43 did gyre and gimble: On Thu, Dec 24, 2009 at 1:29 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 23/12/09 14:35 did gyre and gimble: On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. Can you give links to these bug reports please? read up my use case and read up Halim's use case, have a look at freshmeat.net how many projects are broken because of pulseaudio. My advice is to make your way optional, add a configuration option which provides a compatibility mode. You want to improve audio with linux? then please do so. You guys spent alot time on everything already and something like that should not be a showstopper. So no actual bug reports then? Heh. I think the issue is resolved. apt-get remove pulseaudio is the preferred way to get audio work again. I don't see the reason why someone should use a faulty audio system. Alsa is working well enough for most applications, for the rest Windows and OSX have to be used. Haha, sure whatever works for you. All I'm saying is do you expect us to trawl the internet and dig up problems without any kind of technical detail or debug info attached to them or do you think we should concentrate on answering and dealing with problems in a prescribed and constructive way - e.g. via our BTS. Honestly, give us solid bug reports and we'll attempt to fix the problems reported, but don't come here spreading FUD and talking bullshit throwing accusations without backing them up with anything other than heresay. What I want for Christmas is BUG REPORTS with proper debug information and trigger cases. I think it's pretty clear what the problem is. PA does not support multiple users on one system.. I told you if you intend to replace the existing audio system and build up compatibility layers add try to do it right. People might have had an idea back then when they allowed multiple users to access the audio system. The authorization is normally handled by /etc/group, there I can clearly define who is allowed to access audio and who not. You define this behavior as a bug just because you don't seem to understand how the audio system worked before pulseaudio came up - definitely a good way to start. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: I think it's pretty clear what the problem is. PA does not support multiple users on one system.. I told you if you intend to replace the existing audio system and build up compatibility layers add try to do it right. But for you right === the exact same way it used to work. Doing it right for most people === thinking about the problem and solving it in a secure manner Just because something is no longer identical to how it worked before does not mean it's wrong. People might have had an idea back then when they allowed multiple users to access the audio system. The authorization is normally handled by /etc/group, there I can clearly define who is allowed to access audio and who not. Wrong. The authorisation is normally handled by Console Kit and UDEV applying ACLs correct at the appropriate times for the appropriate users. Using groups is old and unmanageable from a policy perspective. You define this behavior as a bug just because you don't seem to understand how the audio system worked before pulseaudio came up - definitely a good way to start. How something used to work and how it should work are two completely different things. Lennart and others have posted perfectly clear explanations of why the old way was broken and insecure. We've fixed that problem now. Yay! Please either argue against these previous comments or accept them and move on. Saying the same thing over and over without addressing the points people raise is both rather rude and pointless. 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] Accessing audio as root
On Wed, 23.12.09 15:26, Halim Sahin (halim.sa...@freenet.de) wrote: Hi Col, 1. I gave you some examples what doesn't work as expected. How should I run my text-to-speech server before login to have audiooutput for reading the login screen? On Fedora at least the screenreader runs as normal process in the gdm pseudo-session which also happens to run a PA instance. So everything should be fine here, and I am quite sure this is not only done on Fedora this way but all other distributions that use a current version of gdm. Of course, if you use KDE things might be different... 2. Running daemons worked well under alsa (see my previous post). I am using every day this setup. Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and as such everything you could do with ALSA before stays available with PA too. However input output deamons should definitely be part of the user session. That is true for PA itself AND any kind of speech daemon and suchlike. 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] Accessing audio as root
On Thu, 24.12.09 13:43, Markus Rechberger (mrechber...@gmail.com) wrote: Heh. I think the issue is resolved. apt-get remove pulseaudio is the preferred way to get audio work again. I don't see the reason why someone should use a faulty audio system. Alsa is working well enough for most applications, for the rest Windows and OSX have to be used. Great idea! Especially since both MacOS and Windows also limit audio playback to the current active session. It's some amazing logic that you find redemption in two OSes that expose exactly the same behaviour as you hate so much about PA/CK. 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] Accessing audio as root
On Thu, 24.12.09 15:02, Markus Rechberger (mrechber...@gmail.com) wrote: All I'm saying is do you expect us to trawl the internet and dig up problems without any kind of technical detail or debug info attached to them or do you think we should concentrate on answering and dealing with problems in a prescribed and constructive way - e.g. via our BTS. Honestly, give us solid bug reports and we'll attempt to fix the problems reported, but don't come here spreading FUD and talking bullshit throwing accusations without backing them up with anything other than heresay. What I want for Christmas is BUG REPORTS with proper debug information and trigger cases. I think it's pretty clear what the problem is. PA does not support multiple users on one system.. I'd prefer if you'd stop repeating this nonsense, which is simply not true as I already pointed out a couple of times, but which you apparently refused to read. 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] Accessing audio as root
On Fri, 25.12.09 00:47, Ng Oon-Ee (ngoo...@gmail.com) wrote: Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and as such everything you could do with ALSA before stays available with PA too. However input output deamons should definitely be part of the user session. That is true for PA itself AND any kind of speech daemon and suchlike. Lennart I believe in his particular use-case he's concerned about the screenreader prior to the DE starting up (boot messages and the like?). We actually cover that inside of gdm, where you can get access to the boot messages. 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] Accessing audio as root
On Tue, 22.12.09 17:54, Markus Rechberger (mrechber...@gmail.com) wrote: Well, but nevertheless an X session is required to allow differend user accounts to access the audio subsystem at the same time. This is a drawback for me as I'm used to do a lot of my daily work on a text console outside of a X session, so I need to run X just to share audio access between different user accounts. This is a bit confused. PA does indeed *not* allow multiple users simultaneous access to the same audio device. This is because we consider the sound card to be part of the user seat, And this is the problem because it works with alsa, simply add every user you want to give audio access to the audio group and it worked. Even with OSS this worked. But PA breaks this behaviour. First of all, we broke exactly nothing. You can always bypass PA and do stuff like this. Secondly, allowing access to the audio device to all users is a security hole as I tried to explain quite a few times. Allowing that means a user can evesdrop into your voip calls, he can even completely monitor whatever you say when you sit in front of your computer. You don't allow access to your kbd and screen to all users either, right? it was a security issue that has been open for a long long time that access to audio devices was not regulated the same way as acess to your kbd and screen. We fixed that. Just because something works differently than it worked before it doesn't mean it's broken. How about I set up an FM Radio server, there's a daemon process accessible through a website which runs either as root or as his own dedicated audio user - there we already have our use case. If you use a server-like setup, i.e. a headless machine without local sessions, then use system mode of PA. (or bypass PA) I can even imagine that with OSX it does not cause any issue to log in from a remote host and play some audio. Actually OSX does exactly the same thing when you switch between sessions: it stops output from one session and enables output on the other. Mentioning OSX as an example here is really something that can only backfire... Also, as Colin pointed out SSH logins certainly want audio output on the terminal side, not the server side. Please just fix this. There is nothing to fix. the same way as the keyboard, the mouse, or the screen. If we'd allow multiple users access then they might eavesdrop into your voip calls or even record anything you say from the mic. As long as a user is active on a seat he should be the only one who has access to its devices. I don't think it's innovative to cut the possibilities back we had before, it should be up to the user what he wants to do and what not. Right. It is innovative to carry on with the brokeness we always had just because we always had it and not because we would ever think about the brokeness and fix it? Is that what you think? Also, the same discussion we already had 2 years ago on fedora-devel and other mailing lists. Kinda pointless bringing this up again and again and again. 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] Accessing audio as root
On Wed, Dec 23, 2009 at 1:16 PM, Markus Rechberger mrechber...@gmail.com wrote: On Wed, Dec 23, 2009 at 12:57 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 22.12.09 17:54, Markus Rechberger (mrechber...@gmail.com) wrote: Well, but nevertheless an X session is required to allow differend user accounts to access the audio subsystem at the same time. This is a drawback for me as I'm used to do a lot of my daily work on a text console outside of a X session, so I need to run X just to share audio access between different user accounts. This is a bit confused. PA does indeed *not* allow multiple users simultaneous access to the same audio device. This is because we consider the sound card to be part of the user seat, And this is the problem because it works with alsa, simply add every user you want to give audio access to the audio group and it worked. Even with OSS this worked. But PA breaks this behaviour. First of all, we broke exactly nothing. You can always bypass PA and do stuff like this. Secondly, allowing access to the audio device to all users is a security hole as I tried to explain quite a few times. Allowing that means a user can evesdrop into your voip calls, he can even completely monitor whatever you say when you sit in front of your computer. You don't allow access to your kbd and screen to all users either, right? it was a security issue that has been open for a long long time that access to audio devices was not regulated the same way as acess to your kbd and screen. We fixed that. Just because something works differently than it worked before it doesn't mean it's broken. How about I set up an FM Radio server, there's a daemon process accessible through a website which runs either as root or as his own dedicated audio user - there we already have our use case. If you use a server-like setup, i.e. a headless machine without local sessions, then use system mode of PA. (or bypass PA) I can even imagine that with OSX it does not cause any issue to log in from a remote host and play some audio. Actually OSX does exactly the same thing when you switch between sessions: it stops output from one session and enables output on the other. Mentioning OSX as an example here is really something that can only backfire... Also, as Colin pointed out SSH logins certainly want audio output on the terminal side, not the server side. Please just fix this. There is nothing to fix. the same way as the keyboard, the mouse, or the screen. If we'd allow multiple users access then they might eavesdrop into your voip calls or even record anything you say from the mic. As long as a user is active on a seat he should be the only one who has access to its devices. I don't think it's innovative to cut the possibilities back we had before, it should be up to the user what he wants to do and what not. Right. It is innovative to carry on with the brokeness we always had just because we always had it and not because we would ever think about the brokeness and fix it? Is that what you think? Right, we had /etc/group for setting up the permissions pulseaudio breaks this behaviour even with the Alsa compat library. Also, the same discussion we already had 2 years ago on fedora-devel and other mailing lists. Kinda pointless bringing this up again and again and again. Sorry this behaviour is just broken, Pulseaudio should not be part of any distribution until a certain level of compatibility is reached. compiz is optional it's easily possible to enable or disable it. The recommendation to use system mode is also a failure, why should someone reconfigure the entire audio system on a distribution? We have deployed alot devices which depend on audio nowadays at certain b2b customers, guess how many are using pulseaudio? -- exactly noone. After talking to engineers everyone feels like PA is just a pain, and by forcing your ideas which break the default behaviour this situation will not improve. I'd rather like to see a clear statement why it is currently not working, so someone can get onto that topic and fix it. If you want to block it for other users add a configuration option for it but again don't break the default behaviour Just to add, we do not depend on such changes anymore since we suid over to the current running pulseaudio user. But to add some more usecases skeem freshmeat.net and write up a list of how many audio projects you are breaking (because there are quite a few ones who run as daemon). Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 1:49 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 23.12.09 13:16, Markus Rechberger (mrechber...@gmail.com) wrote: Right. It is innovative to carry on with the brokeness we always had just because we always had it and not because we would ever think about the brokeness and fix it? Is that what you think? Right, we had /etc/group for setting up the permissions pulseaudio breaks this behaviour even with the Alsa compat library. Group-based access control is too limited for controlling access to seats in a multi-session environment. That's why we have extended this with mechanisms like ConsoleKit and PolicyKit. Sorry this behaviour is just broken, Pulseaudio should not be part of any distribution until a certain level of compatibility is reached. compiz is optional it's easily possible to enable or disable it. I guess we have to agree to disagree here. ConsoleKit (which is at the core of the multi-session support on our desktops now, including in PA) has been designed 3 years ago and pushed ino all distributions. It's the wrong time to whine about that now, and to me. If you think the whole CK design is an abomination then you are welcome to, but I'd prfer if you'd take that complains somewhere else. The recommendation to use system mode is also a failure, why should someone reconfigure the entire audio system on a distribution? If you run things headless/in a server you have to configure things. Surprise surprise... Also, let me point out that dmix does not support simultaneous output of streams from multiple users simultaneously either by default, for security reasons. You can enable that, but you have to configure that manually and it comes with a big yellow warning sign. This means that PA and ALSA dmix are really not that different in this respect. PA will make use of audio devices it has access to. ALSA dmix can do the same. As long as one user accesses a PA device it is blocked for all other users, which is very much like with ALSA dmix. The only difference is that on ALSA dmix after the user stopped using the device it is immediately accessible to othre users again, while in PA there is a 1s timeout. Not that big a difference. I'd prefer if you'd get your facts right before you start whining. We have deployed alot devices which depend on audio nowadays at certain b2b customers, guess how many are using pulseaudio? -- exactly noone. After talking to engineers everyone feels like PA is just a pain, and by forcing your ideas which break the default behaviour this situation will not improve. I dont force anything. It's Free Software. Take it or leave it. If you don't like it then you are entitled to that, but I find it kinda annoying if you then whine on our mailing lists, and start demanding things. That's not how it works. I am interested in constructive feedback but not at all being accused of forcing. And if we disagree on something then please accept that. I have explained why we do things the way we do. And unless you have a better approach and some code to show I am pretty good at simply going on with what I do. I'd rather like to see a clear statement why it is currently not working, so someone can get onto that topic and fix it. If you want to block it for other users add a configuration option for it but again don't break the default behaviour Did you read any of the emails I wrote in this thread? if not, try it! You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Halim Sahin at 23/12/09 13:24 did gyre and gimble: The Problem can be summarized in one sentence: Pulseaudio currently breaks multiuser systems and is only useful for one-user-desktop. Actually no, the exact opposite. PA works very well for multi user desktops. The vast majority of systems out there have one screen, one keyboard and one mouse. If you have multiple users and want to switch between them PA facilitates this perfectly (in a way that simply does not work with current ALSA and it's implementations. Simply switch user (using your DEs tools for this - typically by clicking Log Out and selecting Switch User or similar. This starts a new X server and allows another user to login in. This second user will now get access to the sound device while the previous user is locked out (but in a nice way) from producing sound). When you switch back and forth between your users (typically ctrl+alt+F7 or F8) the permissions to use the sound device follow which user is active and sound will start and stop appropriately. This is exactly how it should be and PA facilitates this. What you are complaining about is the fact that multiple users cannot use the sound hardware *at the same time* but this is really not how things should work for all the reasons listed on this thread already. It's not how it's done in Windows and it's not how it's done on OSX. We have parity with the current OSX and Windows implementations with PA in this regard. Running more pulse servers at a time can work but is difficult for setup. No it's not. It's the standard out of the box setup. Each user who logs in will get their own PA server automatically via XDG autostart .desktop files or PA autospawning. 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] Accessing audio as root
'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. Can you give links to these bug reports please? 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] Accessing audio as root
Hi Col, 1. I gave you some examples what doesn't work as expected. How should I run my text-to-speech server before login to have audiooutput for reading the login screen? 2. Running daemons worked well under alsa (see my previous post). I am using every day this setup. Speechd runs with uid speech-dispatcher and I can also play sound as user halim. Please don't tell us that this isn't or wasn't possible. Please try to understand the problem and help if you can. I like pa and it's great new features. But it introduced problems wich should be fixed. Your given examples are related to x-sessions. Go one step back. gdm starts and the screenreader-speech-server (before login). If pulseaudio starts at this time, it would use gdm uid. In this case the audiocard can't be used by another pulseaudio after successful login. Please correct me when Iam wrong. Greetings Halim ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. Can you give links to these bug reports please? read up my use case and read up Halim's use case, have a look at freshmeat.net how many projects are broken because of pulseaudio. My advice is to make your way optional, add a configuration option which provides a compatibility mode. You want to improve audio with linux? then please do so. You guys spent alot time on everything already and something like that should not be a showstopper. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, 26.11.09 01:27, David Csercsics (a...@shaw.ca) wrote: On Thu, Nov 26, 2009 at 04:51:25PM +0800, Markus Rechberger wrote: Hi, I've been working quite a while with pulseaudio, one thing that breaks alsa compatibility is that since PA is user based root is not allowed to access audio. This always worked with native Alsa even if root is not in the audio group. I have a similar question here. What should i do if I need to configure things so that sound can play as root as well as my normal user and [preferably before I log in. It is considered incorrect to run pulseaudio in system wide mode and I don't know that I want to take the performance hit anyway. If it matters I don't habitually run X. I bring that up because it seems pulseaudio interacts quite a bit with hal and the X sessions among other things and this case is not covered in the documentation exactly. I'm running this on my laptop so it's not really the embedded case that system mode is designed for but I'd like the low power and hotplug parts of pulseaudio and better mixing than dmix to try to get some more or less useful music playing out of the laptop. The laptop is currently running Fedora but help that is not distro specific would be useful because I sometimes need to fix other Linux boxes and I'm not loyal to any particular system. And I just like to learn how things work. I'm just a little bit confused about how this is supposed to work. Thanks for reading this and I'll play around with it a bit more myself and see if I can hack something up. Generally, it is simply wrong to play music as root. Which is why we don't really support it. There are mostly two reasons why folks might want audio as root: 1) they do the full X login as root. This is just wrong. Everyone who does this deserves having broken audio. If you want to switch to root for admin purposes, do so temporarily, using sudo or a similar tool. And certainly don't play any audio as root! 2) They want to run some system service that runs as root and which wants to play some audio. This is often misguided. If you have a system service running as root you already lost, you should run as its own system user, not root. A good example how this is fixed properly is gdm. The gdm login screen runs under its own gdm user which runs its own PA instance, and everything is good. So generally I believe playing audio back as root is just wrong. And unless someone convinces me otherwise (very unlikely) I don't plan to support it any better than we do right now. 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
