'Twas brillig, and Halim Sahin at 25/08/10 16:25 did gyre and gimble: > Hello, > On Mi, Aug 25, 2010 at 03:46:56 +0100, Colin Guthrie wrote: > > >>> FWIW, I agree that's the best aproach. >>> But aren't you PA guys actively fighting this idea? You strongly advise against >>> system mode. >> >> No, you're misunderstanding what I'm suggesting. >> >> I'm not referring to PA, I'm talking about your speech system. >> >> Halim said previously: >>> A big problem is that the same user has to start several instances of >>> sbl on every console which is hard to implement. >> >> This is what I was referring to when I said you should not run several >> instance of it. Your systems should be split cleanly so that they >> provide a single system wide service that gathers all the necessary >> information (i.e. what is on screen to go via tts), but they should >> *not* actually play the speech they generate, but rather *make it >> available* to whomever wants to consume it. > > That's the point how should the screenreader (sbl) put it's information > for later connection consuments? I didn't use the word "later". I expect that any it pushed this information to any/all agents that happen to be connected and if none are connected then it simply throws it away/does not collect the information in the first place. > The information which is available from the screenreader should be > processed immediately. Of course. > When we start first a pseudo session on plain consoles (dont know) if > this is possible, then the screenreader could connect to it at tthat > time. > The connection will be invallid when the user logs in. > The running speech-dispatcher from the pseudo session > would loose access to pulseaudio, the pulseaudio started at that time > will suspend and a new pulseaudio takes control over audiosystem in the > user's context. > Now the screenreader won't be able to output anything because it's > connection isn't valid. This is the bit that is wrong. Do not thing of the architecture as one agent connecting to one or more PAs. It's one agent per pa (or rather one agent per user). speech-dispatcher itself can do all the necessary work in a system-wide process but only the speech-dispatcher-agent will actually cause any audio to be output. The agent runs as the same user as the PA process (whether this be the pseudo session's "user" or the real user). So when a login prompt is shown, the "idle" or "login" session is active. It is configured to have speech-dispatcher-agent (s-d-a) running and thus it in turn also spawns PA automatically and speaks what is on screen. The user logs in, the "idle" sessions PA is suspended and for the same reasons the "idle" session's s-d-a should also "suspend" itself (whether this means exiting or staying resident isn't really important). When the user logs in they have configured things such that they run a s-d-a which in turn spawns the user's PA and reads things out accordingly. > Well starting the screenreading in the user process is not > possible. Why not? > Connecting a running speech-dispatcher from the usercontext would be > possible if you allow inet socket connection but there is an aditional > restart of the screenreading needed any way. I'm not sure I understand this restriction. > Maybe you can understand now that the things started to be a problem for > us after pa replaced the audiosystem in most popular distros. > And mails like: > http://www.mail-archive.com/pulseaudio-discuss at mail.0pointer.de/msg05948.html > Shows us that we were not understood. > _We_ need and we _Want plain textconsoles! That is not misunderstanding - it's a difference of opinion. If you really want and need plain text consoles then proper session management for console logins needs to be implemented that works properly.... And for what it's worth, this approach is not something that PA itself is fundamentally doing. Yes PAs architecture is aligned to the security model it implements but that doesn't mean that the same security model would be implemented any different in modifications to other systems involved. e.g. ensuring that dmix only works for the user that started it and has permission on the h/w nodes would cause the same problems. >>> I'm seriously confused as to whether you're telling Halim here "you need more >>> effort than just dmix" or in fact "PA is not (and won't ever be) for you". >> >> I'm saying that the way that the tts systems are working need to be revised. > > And who should implement this? > you have pushed the new approach without any backward compatibility > layer. > So all other projects needs to do hard work to get their projects > working in current distros. Sorry but I'm not specing out anything in particular nor am I designing any software that implements it. I'm just explaining the consensus that was reached when we discussed this to death before. >> You can either run separate full systems for each login psuedo session, >> or you can split things out into server-client model whereby the server >> runs as a system service and agents, running as users, connect to it and >> playback the sound (and/or push visuals onto the X11 window). The agents >> run as the local user (real or pseudo) and no unauthorised process has >> access to the sound or display h/w when they shouldn't. > > that is the point. > 1. is not possible Screenreader running on textcsonole can't be work in > userspace. And why not? > 2. The screenreader is a client not a server. > The tts system is a server and must be connected from the screenreader. Well in that case it sounds rather like the screenreader itself is already what I've referred to as agents before. Just run the screenreader as the "idle" user when waiting to log in and gracefully hand over to a the user's own screenreader process when he actually logs in. > BTW.: I am not aware that canonical does work on the > screenreaderproblem. > They simply mooved tts system to userspace and that's it. I'm not aware of this, but I know Daniel and Luke discussed it a lot in the past. As I stated originally, I'm not sure this was official Canonical work but rather work they were looking to do in free time, but that is something that can clearly vary due to workload etc. Speaking of workload, I've tried to restate things as clearly as I can, but I likely will not reply further on this thread unless something different crops up that needs addressing. 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/]
