How to encourage more developers to be involved

[cbr]

Perhaps speech-dispatcher?

[hiran]

But then I tried something else: I turned off 'spoken messages'. And performance was stable, even with high traffic.
So whatever the root cause for the effect, it is connected to the TTS engine.

Wondering: is it possible for voice output to reckognize it is taking too much time for the events coming in?

It could then reduce the amount of words or messages but keep the ship maneuverable and the game playable.

[another_commander]

Wondering: is it possible for voice output to reckognize it is taking too much time for the events coming in?

It could then reduce the amount of words or messages but keep the ship maneuverable and the game playable.

eSpeak is spinning separate threads for its purposes as required. Messages are supposed to be played (spoken) while other stuff happens, all without interruption. At least that's how it works on Windows, where this issue does not occur.

I would recommend investigating thread management of the eSpeak library used on Linux. First ensure that it is indeed asynchronous and then see how it is built (compiler flags, debug/release mode, its own dependencies build flags etc) and take it from there.

Edit: Profiling it may also be a good idea.

[MrFlibble]

Two intertwined questions spring to mind.
Would it be better to use the system speech-dispatcher?
What's the reason for the custom version of espeak?

[another_commander]

What's the reason for the custom version of espeak?

I can answer this one. It is custom only on Windows and the reason is that at the time we included it in Oolite all Widows binaries I could find were synchronous ones and therefore unsuitable to be part of a game. The custom one is built to incorporate asynchronous playback.

[MrFlibble]

What's the reason for the custom version of espeak?

I can answer this one. It is custom only on Windows and the reason is that at the time we included it in Oolite all Widows binaries I could find were synchronous ones and therefore unsuitable to be part of a game. The custom one is built to incorporate asynchronous playback.

Great... oh! Looks like there are still some "custom things" going on on the Linux version. I masked the bundled espeak libs, got the expected crash, did a "sudo apt install libespeak1", and got a different crash which hinted at intonation data path being hard-coded (with a double slash, which might make it easier to trace).

Code: Select all

Can't read data file: '/home/flibble/GNUstep/Applications/Oolite/oolite.app/Resources//espeak-data/intonations'

I find the system version at /usr/lib/x86_64-linux-gnu/espeak-data/intonations, which may differ on i386 or other distros. Either way, the hardcoding of it prevents using the system espeak for now.

[another_commander]

Great... oh! Looks like there are still some "custom things" going on on the Linux version. I masked the bundled espeak libs, got the expected crash, did a "sudo apt install libespeak1", and got a different crash which hinted at intonation data path being hard-coded (with a double slash, which might make it easier to trace).

Code: Select all

Can't read data file: '/home/flibble/GNUstep/Applications/Oolite/oolite.app/Resources//espeak-data/intonations'

I find the system version at /usr/lib/x86_64-linux-gnu/espeak-data/intonations, which may differ on i386 or other distros. Either way, the hardcoding of it prevents using the system espeak for now.

Ah yes, the external libs source modifications document mentions this part for Windows: "Special build of the Windows speech synthesis libespeak.dll to enable asynchronous playback. Also, defaults the eSpeak data directory to Resources/espeak-data." Maybe the data directory modification happened also on Linux, but I don't see it documented anywhere.