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 <gmane at 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 if they are logged in mulitple > times). The difference from PA is that speechd-up cannot use > autospawning to launch, which is why I'm suggesting leveraging > console-kit to actually *start* the speechd-up process. > > I'm probably not explaining it very well so I'll try and reiterate when > I'm not quite as tired with a few examples. > > Col > > (Of course all my suggestions today could be way off base so it would be > much better if someone more familiar in the inner workings could > validate (or invalidate!) what I've said before you go off and do > anything implementation wise!) > > > -- > > 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 at mail.0pointer.de > https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss >
