'Twas brillig, and Bill Cox at 03/01/10 16:23 did gyre and gimble: > Speechd-up isn't the only "root" level sound source that's out there. > Espeakup is another alternative to speechd-up which is currently much > more popular, but limited in that it can only use the espeak voice. > From the point of view of developers for such packages, they just want > to write to a sound output interface. Espeakup uses portaudio, and > frankly, I don't want to rewrite that interface (one is enough for > me). These processes, even speechd-up, set custom buffering > parameters in PA (speechd-up requires the tlength paramter to be much > shorter than default). Well in the situation I'm proposing, the speechd-up would actually just write it's audio to a pipe (totally bypassing pulse client API), and it would be up to module-pipe-source and module-loopback to act as the pulse client, reading from the pipe and actually doing the output. The buffering metrics can be somewhat adjusted when loading module-loopback. > Instead of writing modules for PA to talk > directly to speechd-up, Well it wouldn't be specific modules, just using module-pipe-source which already exists. It's just a matter of writing to the chosen pipe in a known format. > why not write modules to allow user-land PA > instances to read from a special global PA instance? That would > simplify life for the root level sound packages greatly, and keep > control of the interaction entirely within PA code. In principle this is not too bad an idea, but I'm really not sure of the implications of this. I guess some sort of system level PA that is triggered from system dbus or similar could work and still allow the use of some of the PA client libraries. The client would have to specifically ask for access to this and I'm still not sure of the overall security model here. All of the suggestions in this thread are pretty "out there" anyway and I'd really like to get some feedback from others (especially Lennart) on the most desirable approach. I think he's heading home soon, so should catch up on the backlog in due course! > Also, thanks a ton, Colin, for all the advice! I tries me best :p 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/]
