'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/]
