retrieving synthesized auio data?

[Luke Yelavich]

On Thu, Feb 04, 2010 at 02:40:34PM PST, Bill Cox wrote:
> Hi, Luke.  Count me in for a supporting role on speech-dispatcher.  I
> was also thinking of enhancing speech-dispatcher to create audio
> files.  There's some discussion on the Vinux list about creating an
> audio book creation app, and sometime over the next year, I'd like to
> see it happen.

Excellent, thanks for your support.

> Personally, I'm not a fan of using dbus for inter-process
> communication.  I prefer file sockets generally, but I'm old-school.
> Actually, assuming we don't mind losing the TCP capability in
> speech-dispatcher, I don't see why speech-dispatcher can't become a
> shared library, with no daemon running.  Do you know a good reason?

Dbus is becoming more and more prevalent, and relevant in distributions today. 
Ubuntu's, fedora's, and eventually Debian's init system require dbus to 
function. Dbus itself uses sockets to do the IPC, with a daemon in the middle 
to handle everything, and the API is relatively simple, easily allowing any 
application to listen into, and make a call out, to the IPC of many an 
application that uses dbus.

As for speech-dispatcher eventually being a shared library, one reason that I 
can think of where the current model is good, is for use with system level 
apps, like BrlTTY, being able to send text to be spoken, and needing to be 
heard out the audio device, which is owned by the user. Mind you, I am starting 
to question the necessity for something like BrlTTY to work like that. So it 
may be worth considering the shared library model.

Maintenance wise, it may make things a little more difficult, particularly when 
bindings to various programming languages, and third-party output modules like 
the speech-dispatcher SAPI output module are taken into account. It also makes 
supporting proprietary speech synthesizers like DECtalk and ibmtts more 
difficult, since users could not use these synths on a 64-bit system. Sure you 
could have separate processes running for the output modules like we do now, 
but if an application were to crash, it would leave processes floating around 
that would never get killed or cleaned up.

You could also turn that the other way around. A user may want to use a 
proprietary client that works with speech-dispatcher. If the client was only 
32-bit, and a user wanted to use it on a 64-bit system, it would require a 
complete 32-bit speech stack to be on their system. Whereas with the separate 
process model like we have now, only the library the client links to and the 
dbus library, if dbus was to be used, would need to be in 32-bit.

Speech-dispatcher has been around for a while now, and such projects as 
speechd-el, and the openSAPI project are able to operate independantly of the 
speech-dispatcher code. Changing the whole model of speech-dispatcher to a 
shared library/plugable object model would break these projects quite hard, and 
would cause a whole lot of extra work that is unnecessary, not to mention the 
speech-dispatcher code refactoring would take a lot of time and effort, for 
what I see as very little gain.

Hope this all makes sense.

Luke