On Sun, 03.01.10 16:34, Colin Guthrie (gmane at colin.guthr.ie) wrote: > > '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. This wont fly. m-p-s assumes the audio you pass to it is clocked. and m-l depends on that. However the tts audio will not be clocked properly, and hence things will make boom.. That said, writing a simple module reads audio data from a pipe and passes directly to a sink should be trivial to do. Note however that on Unix pipes cannot be used to distribute data to multiple processes. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
