last try: ibmtts module broken in current speechd git master

[Christopher Brannon]

Halim Sahin <halim.sahin at t-online.de> writes:

> Hi,
> The module doesn't produce any speechoutput since:
> d3db4f80598bd4b1b06762f76665836651a0d673

I can reproduce this, sort of.
What audio output method are you using?
Here's what I've noticed when using ALSA.  The same will also apply to
libao when libao uses ALSA.
If you're using ALSA or libao via ALSA, are you also using dmix for
software mixing?  You should probably be doing so.  I'll describe the
problems that I've noticed.

First, now that we have module autodiscovery, everything in
/usr/lib/speech-dispatcher-modules gets loaded.  This includes things
like sd_cicero, which are present on my system, but which I will never
use.  It also loads an unnecessary copy of sd_generic, which is never
used for anything.  The discovery code needs another check, to skip
generic.

The real problem, though, is that every module tries to open audio
output.  This is due to the previous refactoring.  Some of them don't
need to at all.  dummy doesn't, and I don't believe that cicero does
either.  Neither does generic, but it loads audio plugins, so that it
knows which play command to use.  We've covered this territory in the
past.  Generic needs to be a little bit smarter, closing the
audio output as soon as it has acquired the information that it needs.

So why am I rambling about this?  I don't use dmix, because I have
hardware mixing, and it is usually sufficient.  However, when I use the
alsa audio output method, and all of these modules start opening the
sound card, one or more will fail.
I think this is what is happening to you with IBMTTS.  It is
failing to open the audio device, because too many other things have
opened it.

But I could be wrong.  You could test this by moving unused modules out
of /usr/lib/speech-dispatcher-modules/, so that they aren't autoloaded.

-- Chris