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