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.

[hiran]

the external libs source modifications document

Where is that hosted?

[another_commander]

https://github.com/OoliteProject/oolite ... hanges.txt

[MrFlibble]

Here's what I've boiled the required lib mess down to.

libespeak.so.1 ( choice of libespeak.so.1.alsa libespeak.so.1.pulseaudio )

Presumably because of the static reference to the espeak-data/intonations.

libgnustep-base.so.1.28
libicudata.so.70
libicui18n.so.70
libicuuc.so.70
libpng14.so.14

Oolite only runs with the exact versions of those which it was built with. Symlinks to newer versions will not work.

While this is not the optimal outcome, I'll update my fork with that presently. I'll also have a look at tweaking the readme files re: requirements.

[hiran]

Here's what I've boiled the required lib mess down to.

libespeak.so.1 ( choice of libespeak.so.1.alsa libespeak.so.1.pulseaudio )

Presumably because of the static reference to the espeak-data/intonations.

libgnustep-base.so.1.28
libicudata.so.70
libicui18n.so.70
libicuuc.so.70
libpng14.so.14

Oolite only runs with the exact versions of those which it was built with. Symlinks to newer versions will not work.

While this is not the optimal outcome, I'll update my fork with that presently. I'll also have a look at tweaking the readme files re: requirements.

This just does not make sense. There is an outdated libespeak.so that was compiled against outdated other libraries, and that's why Oolite needs to be shipped with outdated libraries? Now knowing that libespeak has not even be customized in any way what is the point of sticking to that binary?

[MrFlibble]

Here's what I've boiled the required lib mess down to.

libespeak.so.1 ( choice of libespeak.so.1.alsa libespeak.so.1.pulseaudio )

Presumably because of the static reference to the espeak-data/intonations.

libgnustep-base.so.1.28
libicudata.so.70
libicui18n.so.70
libicuuc.so.70
libpng14.so.14

Oolite only runs with the exact versions of those which it was built with. Symlinks to newer versions will not work.

While this is not the optimal outcome, I'll update my fork with that presently. I'll also have a look at tweaking the readme files re: requirements.

This just does not make sense. There is an outdated libespeak.so that was compiled against outdated other libraries, and that's why Oolite needs to be shipped with outdated libraries? Now knowing that libespeak has not even be customized in any way what is the point of sticking to that binary?

I agree. So what's the fix?

I've got a lot on until next week, but if time permits I'll look at building doing something like apt install libespeak1-dev, and not symlinking the old .h file during build. Same for the other allegedly 'untweaked' deps.

Maybe we can unpickle this 'properly'.

[hiran]

This just does not make sense. There is an outdated libespeak.so that was compiled against outdated other libraries, and that's why Oolite needs to be shipped with outdated libraries? Now knowing that libespeak has not even be customized in any way what is the point of sticking to that binary?

I agree. So what's the fix?

I've got a lot on until next week, but if time permits I'll look at building doing something like apt install libespeak1-dev, and not symlinking the old .h file during build. Same for the other allegedly 'untweaked' deps.

Maybe we can unpickle this 'properly'.

I do not have a real fix, just a hunch.
Thus I believe the latest and greatest libs should be tried - and if compiles just celebrate.
If it doesn't a lot of single issues may need to be looked at.

But it is not reasonable to ship with old libs for the sake of not migrating to newdr libs. The technical debt will grow and eventually there is noone who can be asked.

We may be there yet. Oolite devs are al.ost gone, and everybody who migrated from SDL 1 to 2 is likely on 3 now.

[MrFlibble]

I do not have a real fix, just a hunch.
Thus I believe the latest and greatest libs should be tried - and if compiles just celebrate.
If it doesn't a lot of single issues may need to be looked at.

But it is not reasonable to ship with old libs for the sake of not migrating to newdr libs. The technical debt will grow and eventually there is noone who can be asked.

We may be there yet. Oolite devs are al.ost gone, and everybody who migrated from SDL 1 to 2 is likely on 3 now.

Agreed.

As long as we are mindful of what's available on the most/all of the last and latest distros, in order to advise apt/rpm/whatever installs required, this should be do-able. In the worst case, a few errant libraries from the build system can still be bundled as a workaround for oddball systems.

As soon as I get a chance (probably next week), I'll have a go at unbundling espeak etc.