Oolite Bulletins

One of the few things I envy the Mac for is that it's Oolite has speech.

Well I think we can change it. Over the last few weeks I've been using a new text-to-speech system call eSpeak and I think it would be a good addition to the system. It doesn't use the traditional method of generating speech so it't quite artifical, but I find it clear that Microsoft Anna in many respects and its far more flexible.

The windows version can be installed as both a command line program and a SAPI5 module. The system is multi-language and sports customisable gender and accent modes (I use it with a Scottish female setting.) The command line version is only 251Kb in size and is self-contained. It's released under GPL 3.0 and as the programmer originally created for the Acorn Risc computers, I suspect he might be happy to see it being used in Oolite.

One other final bonus is that there is a Linux version as well

Anyway I offer this possible solution to our minor but still eking problem, for the mighty programmers for their cast their eye on.

Looks like a good solution all right.. what a bummer that trunk is in feature freeze mode now, so this would have to wait for 1.74... (can we declare that since the Mac version has speech, the fact that Win/Lin does not is technically a bug? )

We are long aware of the espeak library and the Linux port of Oolite is using it already. However, this library is not the optimal solution for Windows for the following reasons:
1. No asynchronous playback support in the standard espeak dll version for Windows. In simple terms, when speech must be generated, the game stops while text is being spoken, then continues. For other types of applications this might be OK, but unfortunately, for a game this is equal to epic fail.
2. The SAPI5 dll version must be registered in the system before using it. This complicates seriously the setup of Oolite and introduces direct interaction with the Windows Registry, which is something I would prefer to stay far, far away from.
3. I could be wrong on that, but from what I have seen so far, it creates plenty of clutter with files that it needs in order to work. It would be great if the amount of files required could be minimized to one or two and if anyone knows how this can be done, I would be interested to know.

For what is worth, I have tried already building Oolite with espeak support and managed to hack something up that works (with asynchronous playback) for about 45 seconds before crashing. It was good, but honestly, I would prefer something less of a hassle, in order for the result/effort ratio to be within my tolerances.

Having said that, after 1.73 I might try to rebuild espeak with an older libportaudio (a required support library) version, hoping that I will be able to have a Linux-like end product that can be used without problems.

Well I stand (post ) corrected then. I thought that might be the case but I you don't know unless you suggest these things. Perhaps A_C (or others) could you answer me this then.

I did a bit of reading up on SAPI5 and found that the Microsoft code libraries for it are free for use. Add that Vista, 7, and later versions of XP have the ms version of the dll already installed. So why have there been issues in adding support for it?

It's not that I'm complaining mind you. I ask more out of general interest and to understand the trials and tribulations that you folks go through in giving us plebs' such gaming bliss.

The SAPI dlls might be free and available, but interfacing with them is the real problem here. Having the dlls available means nothing to us if we do not have access to the actual headers and import libraries too (minor detail: the import libraries must be readable by GCC). As I said earlier, using these dlls requires them to be system-registered. This means certain calls to the registry must be made for a program to use them and I do not want Oolite to become dependent on the Windows Registry in any way. Additionally, although I have searched a lot, I have not been able to find a single example of using the espeak SAPI5 dll together with any other program. The example espeak application that comes with the distribution very conveniently links everything it needs statically, so it does not use the dll found in the same folder at all.

What we need is an espeak DLL that functions like the standard Windows one, but with asynchronous playback enabled. This can only be done by either a) adding Windows style thread manipulation in the espeak code (and I am certainly not going to do this, neither do I think anyone else from our team will) or b) attempting to build a Linux-style dll by utilizing the older version of libportaudio - assuming that it works as desired - and the pthreads library port for Windows, which will be needed for threading support. This is by no means an easy task and therefore it goes for "later".

There are two possible problems with the ms stuff:

The first is technical, but we might be able to sort it out relatively painlessly (said he, haven't tried to make ms's headers gcc compatible yet).

The second one is legal: we do need to check the licensing terms, ms might not allow sapi5.dll to be linked too freely by open source applications, or us to modify the headers they provide.

But we'll definitely have a good look inside microsoft's sapi 5 sdk, it might well prove to be the simplest way to add asynchonous speech to Oolite-windows!

Thanks for the information. I am now a little bit more enlightened. I would not expect for you folks to deal with my suggestion till post 1.74 since there are so many other more important features to be implemented and tested first.