[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
retrieving synthesized auio data?
retrieving synthesized auio data?
Thu, 4 Feb 2010 15:20:40 -0800
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.
TTS API Provider and Retrieving synthesized audio data, Hynek Hanke, 2010/02/05