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
