Re: [pulseaudio-discuss] Using pulseaudio with speakup
On Fri, 01.01.10 16:58, Bill Cox (waywardg...@gmail.com) wrote: However, even with these changes, there are bugs due to pulseaudio's user-based structure. Today, in Karmic, if I 'switch user' to another use, my new gnome session has no sound. That's because there are two pulseaudio processes running, and the first one takes over control of the sound card and does not share. PA should hand over the device as the session is switched. This works fine on Fedora. if it doesn't on Ubuntu make sure to file a bug on LP. 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] Using pulseaudio with speakup
Le 01/01/2010 22:58, Bill Cox a écrit : Are there any ways to get pulseaudio to share the sound card? http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/module-console-kit.c;hb=HEAD PA hooks into ConsoleKit and turns itself off when the active user changes. So yes, the daemon is still running but all audio devices should be free for a new user to grab. Of course, if your distro doesn't enable the consolekit module... Cheers, Rémi ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
'Twas brillig, and Bill Cox at 01/01/10 21:58 did gyre and gimble: However, even with these changes, there are bugs due to pulseaudio's user-based structure. Today, in Karmic, if I 'switch user' to another use, my new gnome session has no sound. That's because there are two pulseaudio processes running, and the first one takes over control of the sound card and does not share. Other folk have replied now but just to explain in detail for clarity: It is by design that multiple pulseaudio processes run at the same time but the idea is that they gracefully drop access to the actual sound hardware when the given user is not supposed to have access. This is why the gdm user has direct access at the login window and then when a user logs in it gracefully hands control over to the real user. Again switching users should all just work. PA should remain running even when the user does not have current access to the hardware as it will cork it's streams (a sort of equivalent to pause) and as more applications are aware of the concept of corking they will be able to adjust their UI accordingly. We can also issue corks for other reasons (e.g. a voip call comes in so the music and video apps are corked/paused. So whatever problem you are having switching users would seem to suggest a problem with consolekit and/or the consolekit module in PA. Use the program ck-list-sessions to see which user is currently active to debug this further. Daniel's earlier comments about the different users are the wait forward to debug further. 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] Using pulseaudio with speakup
'Twas brillig, and Markus Rechberger at 02/01/10 01:56 did gyre and gimble: Can you point out to a few requests where people had serious issues with shared audio access during the last 10 years, other unix systems get along quite fine with shared support. The hacking argument is just nonsense, I highly doubt that it has any relevance for real. sarcasm Yeah, we should probably just trust all the nasty people in the world not to exploit this hole. That's my preferred model of security too. /sarcasm -- 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] Using pulseaudio with speakup
Hi, Colin. Here's what I'm thinking of doing. I think PulseAudio should support the concept of a global sound source attached to a card, and whichever pulseaudio system has rights to use the card should be responsPible for processing the global source. Any pulseaudio client could declare themsevles a global source, but to be considered authorised, they must be of a special global source group, or perhaps run as a special global source user. It is clear to me, and I hope becoming clear to you, that there are a few special cases where a process needs continuous access to the sound card, and needs to share it with the user. Speakup is one. But even looking at this, it's actually multiple cases. Speakup just creates the /dev/speakup_soft device, which speakup clients read to produce speach. Two popular drivers exist, both with PA backends: speechd-up/speech-dispatcher, and espeakup. I'm sure there are more reasons for other sound drivers to be considered global. Would this scheme be in keeping with PA security? It seems to me that it would be pretty secure: it's only a sound source, and there's no possibility of accessing the mic, for example, and only special processes can use it. If this is acceptable, I volunteer to write it. Thanks, Bill On Sat, Jan 2, 2010 at 8:17 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Bill Cox at 01/01/10 21:58 did gyre and gimble: However, even with these changes, there are bugs due to pulseaudio's user-based structure. Today, in Karmic, if I 'switch user' to another use, my new gnome session has no sound. That's because there are two pulseaudio processes running, and the first one takes over control of the sound card and does not share. Other folk have replied now but just to explain in detail for clarity: It is by design that multiple pulseaudio processes run at the same time but the idea is that they gracefully drop access to the actual sound hardware when the given user is not supposed to have access. This is why the gdm user has direct access at the login window and then when a user logs in it gracefully hands control over to the real user. Again switching users should all just work. PA should remain running even when the user does not have current access to the hardware as it will cork it's streams (a sort of equivalent to pause) and as more applications are aware of the concept of corking they will be able to adjust their UI accordingly. We can also issue corks for other reasons (e.g. a voip call comes in so the music and video apps are corked/paused. So whatever problem you are having switching users would seem to suggest a problem with consolekit and/or the consolekit module in PA. Use the program ck-list-sessions to see which user is currently active to debug this further. Daniel's earlier comments about the different users are the wait forward to debug further. 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] Using pulseaudio with speakup
Hi, Colin. Sorry about always replying at the top. This is the usual custom for the blind, as they can't easily skip down to the new stuff. I'd prefer not to write new PA modules for each accessibility driver. I think it's very important to make it as easy as possible for existing accessibility drivers to work seamlessly with PA, and we don't want to polute the PA module space with a dozen accessibility modules (there are actually quite a lot of programs that talk - I've just mentioned the most important). I like your suggestion of CK understanding an idle state. Does it already have hooks for when applications pause their audio? How about if they disable the mic? Another important accessibility feature is speech-recognition. You aren't hearing from a bunch of mad users who can't type simply because Linux speech recognition basically sucks right now. When that changes, we're going to need the speech regcognition engine to play nicely just like speakup. Users will need to speak their login and password, and they'll need it when they su to root. Does CK have a way to tell Skype running as bill that the speech-recognition engine running as dragon-dictate has corked it's use of the mic? Adding such hooks, or using existing ones sounds very promising to me, though I'm nearly 100% ignorant currently of CK. Bill On Sat, Jan 2, 2010 at 10:01 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Bill Cox at 02/01/10 14:20 d isid gyre and gimble: Hi, Colin. Here's what I'm thinking of doing. I think PulseAudio should support the concept of a global sound source attached to a card, and whichever pulseaudio system has rights to use the card should be responsPible for processing the global source. Any pulseaudio client could declare themsevles a global source, but to be considered authorised, they must be of a special global source group, or perhaps run as a special global source user. This is quite easy to say but certainly very difficult to actually write. Even if there are 5 users logged in and running 5 separate PA instances, each users' PA clients will be talking to totally separate PA daemons and each will be essentially ignorant of the others existence (as they should be). There is something that can be done however It is clear to me, and I hope becoming clear to you, that there are a few special cases where a process needs continuous access to the sound card, and needs to share it with the user. Speakup is one. But even looking at this, it's actually multiple cases. Speakup just creates the /dev/speakup_soft device, which speakup clients read to produce speach. Two popular drivers exist, both with PA backends: speechd-up/speech-dispatcher, and espeakup. I'm sure there are more reasons for other sound drivers to be considered global. With this module, is there any reason to not write a PA module that processes this /dev/speakup_soft node and does the necessary? e.g. the speechd-up or espeakup code basically ported to a PA module? It doesn't really solve the overall problem of when to start it tho', so not sure it's really worth it. PA will be started at X11 login or when it is needed (e.g. something tries to output sound and PA is not yet running) via it's autospawning system. Having module-speakup will not cause autospawning, so it would rely on PA being started for it to work, which is the same situation as currently. I sent a (rather long) reply earlier today that talks about making console-kit aware of idle state and having various hooks for it. I think (at the moment) that this is probably the right direction for accessibilty apps. i.e. PA just works as normal (and is launched when needed) but console-kit itself is the thing that can be used to hook into for an accessible system. I'm happy to accept counter arguments tho'!! Would this scheme be in keeping with PA security? It seems to me that it would be pretty secure: it's only a sound source, and there's no possibility of accessing the mic, for example, and only special processes can use it. I think it would be fine, but again the problem is more related to starting PA in the first place not so much it dealing with a global source per se. I hope the longer reply from earlier today is understandable and I'm not smoking too much crack :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
Re: [pulseaudio-discuss] Using pulseaudio with speakup
'Twas brillig, and Bill Cox at 02/01/10 16:04 did gyre and gimble: Hi, Colin. Sorry about always replying at the top. This is the usual custom for the blind, as they can't easily skip down to the new stuff. No problem, exception to bottom posting duely noted :) I'd prefer not to write new PA modules for each accessibility driver. I think it's very important to make it as easy as possible for existing accessibility drivers to work seamlessly with PA, and we don't want to polute the PA module space with a dozen accessibility modules (there are actually quite a lot of programs that talk - I've just mentioned the most important). Yeah, that makes sense and like I said even writing a module doesn't actually solve the problem anyway, so probably best to ignore this. I like your suggestion of CK understanding an idle state. Does it already have hooks for when applications pause their audio? How about if they disable the mic? No, console-kit isn't aware of audio per-se. It's just a generic part of the core infrastructure tracking user logins, active sessions etc. Another important accessibility feature is speech-recognition. You aren't hearing from a bunch of mad users who can't type simply because Linux speech recognition basically sucks right now. When that changes, we're going to need the speech regcognition engine to play nicely just like speakup. Users will need to speak their login and password, and they'll need it when they su to root. That may be a larger problem due to user permissions etc. (e.g. why should the idle user be allowed to send keys to mingetty etc.) but I'm sure there will be a way to solve this (some sort of setuid app to send the keys or similar). Does CK have a way to tell Skype running as bill that the speech-recognition engine running as dragon-dictate has corked it's use of the mic? No, this is not what CK is all about. Also remember that the ultimate goal is to always run apps as the user that is currently active: e.g. dragon-dictate (the application) would run as bill (the user) or as the idle user in the case of a login prompt. Adding such hooks, or using existing ones sounds very promising to me, though I'm nearly 100% ignorant currently of CK. Well we're all ignorant of something until we look into it :) As I said above, all ck does is track which users are logged in (e.g. on tty consoles, on X11 sessions, via SSH etc). It will generally only designate one user as active per seat (most machines only have one seat, but you can run a multiseat setup with relative ease). This information is used to let the active user get direct access to the machines resources - e.g. the sound hardware, the video hardware etc. All pulseaudio really does is listen to console-kit and honour what it says is the case - only allowing the currently active user access, but still providing a structure and framework for apps so that they don't just crash or behave badly when they suddenly have their audio rights yanked away from them. We can just use the information exposed from CK to know when we are or are not active. The ultimate goal is to run as many apps as possible under the user account of the person using them. Every other system user that allows regular users to communicate with them is a potential privilege escalation hole. So the suggestions I've made are basically to run the apps at the appropriate times as the appropriate user using console-kit as the central information source as to what the active user actually is. 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] Using pulseaudio with speakup
Thanks, Colin. I can probably modify speech-dispatcher and speechdup-d to run as gdm on boot. I can probably also modify gdm code to look for speech-dispatcher and speechd-up as well, and relaunch them. It definately feels weird mucking about with the login package, though. However, even with these changes, there are bugs due to pulseaudio's user-based structure. Today, in Karmic, if I 'switch user' to another use, my new gnome session has no sound. That's because there are two pulseaudio processes running, and the first one takes over control of the sound card and does not share. Are there any ways to get pulseaudio to share the sound card? If not, doesn't it make more sense to have a single pulseaudio deamon, so multiple users can share it? I'm frankly not aware of actual instances of one user listening on the mic of another, for example, nor any other actual sound system security hack in the wild. I prefer to fix problems that actually happen, rather than dream up imaginary problems and then offer complex solutions. For example, I have a real problem in that pulseaudio doesn't work with speakup and Orca at the same time, and it wont allow me to switch user and get sound as the new user. We can keep building hacks, like modifying gdm to restart yet more sound processes (speechd-up and speech-dispatcher, for example), and we could hack switch-user to do the same, or we could realize we're spending a lot of effort fixing a problem that isn't real. Anyone out there every get hacked because you shared the Alsa back-end with another user? Anyone? Thanks, Bill On Thu, Dec 31, 2009 at 12:27 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Bill Cox at 31/12/09 17:13 did gyre and gimble: Thanks for the info. Is there a simple way to kill off the gdm pulseaduio when the user logs in? Some sort of hook I can tie into? It should all happen automatically: console-kit will hand over the active session to the user logging in and PA will play nicely with that. I've not looked into this in huge depth so can't really advise more than that - hopefully I'll find time to play and/or Lennart/someone else will be able to advice more practically. 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] Using pulseaudio with speakup
On Fri, Jan 1, 2010 at 4:58 PM, Bill Cox waywardg...@gmail.com wrote: However, even with these changes, there are bugs due to pulseaudio's user-based structure. Today, in Karmic, if I 'switch user' to another use, my new gnome session has no sound. That's because there are two pulseaudio processes running, and the first one takes over control of the sound card and does not share. Are they the same user id? I suspect there's something wonky occurring with ConsoleKit. See ck-history --log and ck-list-sessions. -Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
No, the problem happens when I switch to a new user. On Fri, Jan 1, 2010 at 5:08 PM, Daniel Chen seven.st...@gmail.com wrote: On Fri, Jan 1, 2010 at 4:58 PM, Bill Cox waywardg...@gmail.com wrote: However, even with these changes, there are bugs due to pulseaudio's user-based structure. Today, in Karmic, if I 'switch user' to another use, my new gnome session has no sound. That's because there are two pulseaudio processes running, and the first one takes over control of the sound card and does not share. Are they the same user id? I suspect there's something wonky occurring with ConsoleKit. See ck-history --log and ck-list-sessions. -Dan ___ 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] Using pulseaudio with speakup
pe, 2010-01-01 kello 16:58 -0500, Bill Cox kirjoitti: Anyone out there every get hacked because you shared the Alsa back-end with another user? Anyone? I don't think anyone is going to get hacked because of this - it's rather rare that you say your passwords aloud. Instead of hacking issue, it's a privacy issue on shared machines. You can try arguing against that as long as nobody reports real cases of eavesdropping, but I think this is a rather obvious problem... -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
On Sat, Jan 2, 2010 at 2:21 AM, Tanu Kaskinen ta...@iki.fi wrote: pe, 2010-01-01 kello 16:58 -0500, Bill Cox kirjoitti: Anyone out there every get hacked because you shared the Alsa back-end with another user? Anyone? I don't think anyone is going to get hacked because of this - it's rather rare that you say your passwords aloud. Instead of hacking issue, it's a privacy issue on shared machines. You can try arguing against that as long as nobody reports real cases of eavesdropping, but I think this is a rather obvious problem... Can you point out to a few requests where people had serious issues with shared audio access during the last 10 years, other unix systems get along quite fine with shared support. The hacking argument is just nonsense, I highly doubt that it has any relevance for real. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
la, 2010-01-02 kello 02:56 +0100, Markus Rechberger kirjoitti: On Sat, Jan 2, 2010 at 2:21 AM, Tanu Kaskinen ta...@iki.fi wrote: pe, 2010-01-01 kello 16:58 -0500, Bill Cox kirjoitti: Anyone out there every get hacked because you shared the Alsa back-end with another user? Anyone? I don't think anyone is going to get hacked because of this - it's rather rare that you say your passwords aloud. Instead of hacking issue, it's a privacy issue on shared machines. You can try arguing against that as long as nobody reports real cases of eavesdropping, but I think this is a rather obvious problem... Can you point out to a few requests where people had serious issues with shared audio access during the last 10 years, other unix systems get along quite fine with shared support. The hacking argument is just nonsense, I highly doubt that it has any relevance for real. No, I can't point out such requests. I answered your question even before you asked it, and you even quoted the answer: You can try arguing against that as long as nobody reports real cases of eavesdropping, but I think this is a rather obvious problem. Obviously you don't think it's so obvious. That's fine, we can agree to disagree. My opinion doesn't matter anyway. Personally, if I shared a computer, I would be happy to know that the other people can't eavesdrop me without root access and knowledge of how to tweak the behaviour of consolekit or hal or whatever actually does the device access control modifications. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
I was able to get to a semi-good state by not having pulseaudio autospawn in /etc/pulse/client.conf. The computer comes up silent until I log into gnome, and Orca works. When I switch to a console, it's silent until I log in and restart speechd-up. The problem is that there is no audio at the console until I log in. There is also no audio at the gnome login. Grr... Isn't there any way to get audio working before a user logs in? Bill On Thu, Dec 31, 2009 at 10:34 AM, Bill Cox waywardg...@gmail.com wrote: I am trying to get Ubuntu/Lucid working well with applications for the blind and visually impaired. Orca is working quite well now with pulseaudio. The other critical application is speakup, which reads text on the Ctrl+Alt+F1-6 consoles. Speakup has issues with pulseaudio, and I need some advice about working them out. It is important, but not required, that speakup run before the user logs in, so it can read the login prompt and some system messages. Ideally, it does this with speechd-up which talks to speech-dispatcher which generates speech through pulseadio. Thus, once speakup starts, it sounds like I need to somehow launch pulseaudio, as some user like gdm. When the user logs in, speechd-up needs to switch to talking to that user's instance of pulseadio, so that speach from both the console windows and Orca can stream through the same instance of speech-dispatcher. However, when I try this, the gdm version of pulseaudio seems to grab the sound card, and the second instance is mute. The obvious solution is for me to just run one copy of pulseaudio (as root?) at boot time and make all users access that copy, just like the older sound systems. However, I understand that is frowned upon by the pulseaudio developers. What is the right solution? Remember, I need sound both before logging in, and after, and they need to play nice, as the console windows may not be logged in, while the Gnome desktop is. I also prefer sound from speakup to work as soon as the module is loaded. I understand the old system for doing this, but not how to make it work with pulseaudio. Any help is appreciated. Thanks, Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
'Twas brillig, and Bill Cox at 31/12/09 16:07 did gyre and gimble: The problem is that there is no audio at the console until I log in. There is also no audio at the gnome login. Grr... AFAIK, the GDM login relies on autospawning, so turing off auto spawning will result in no sound at gdm login. As for speechd-up I'd recommend running it as the gdm user, not as a system user, then when the real user logs in, the gdm user's PA and speechd-up processes should die and a version for the user who is logging in should be run in it's place. I think this configuration has been discussed quite thoroughly over the last couple weeks. I'm not familiar with it, so speechd-up may require modification to work this way but it certainly seems like the most logical and secure way to run the system (the same would be true of timidity too I believe). 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] Using pulseaudio with speakup
Thanks for the info. Is there a simple way to kill off the gdm pulseaduio when the user logs in? Some sort of hook I can tie into? Thanks, Bill On Thu, Dec 31, 2009 at 11:26 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Bill Cox at 31/12/09 16:07 did gyre and gimble: The problem is that there is no audio at the console until I log in. There is also no audio at the gnome login. Grr... AFAIK, the GDM login relies on autospawning, so turing off auto spawning will result in no sound at gdm login. As for speechd-up I'd recommend running it as the gdm user, not as a system user, then when the real user logs in, the gdm user's PA and speechd-up processes should die and a version for the user who is logging in should be run in it's place. I think this configuration has been discussed quite thoroughly over the last couple weeks. I'm not familiar with it, so speechd-up may require modification to work this way but it certainly seems like the most logical and secure way to run the system (the same would be true of timidity too I believe). 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] Using pulseaudio with speakup
'Twas brillig, and Bill Cox at 31/12/09 17:13 did gyre and gimble: Thanks for the info. Is there a simple way to kill off the gdm pulseaduio when the user logs in? Some sort of hook I can tie into? It should all happen automatically: console-kit will hand over the active session to the user logging in and PA will play nicely with that. I've not looked into this in huge depth so can't really advise more than that - hopefully I'll find time to play and/or Lennart/someone else will be able to advice more practically. 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
