On Sun, 03.01.10 07:41, Bill Cox (waywardgeek at gmail.com) wrote: > > 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? Why do you second-guess us, but not them? In the long run device access for root wont work anyway, for example, when you acre about more than ALSA kernel devices, such as bluetooth or other stuff that might need user supplied security credentials. audio output as root is broken. > 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? Works fine here. If two users log in then access to the audio device is handed over to the active user as soon as you switch to it and removed from now inactive user. Audio is automatically paused for inactive users and resumed as soon as they become active again. > 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? First of all, PA is really not that complex in this area. We simply watch the permissions on the device nodes and close the device/pause playback if we loose access and reopen the device/resume playback if we get access again. From a high-level perspective there is nothing easier than that. Secondly, the whole udev/CK logic has originally been designed independantly of PA. If you thinkg that PA is overcomplex in this design, then I'd like to ask you to redirect your complains to the udev/CK folks. > 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. That's FUD. And that's why I will ignore it. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
