How to encourage more developers to be involved

An area for discussing new ideas and additions to Oolite.

Moderators: winston, another_commander

User avatar
cbr
---- E L I T E ----
---- E L I T E ----
Posts: 1520
Joined: Thu Aug 27, 2015 4:24 pm

Re: How to encourage more developers to be involved

Post by cbr »

Perhaps speech-dispatcher?
User avatar
hiran
Theorethicist
Posts: 2473
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: How to encourage more developers to be involved

Post by hiran »

hiran wrote: Thu Jul 03, 2025 8:10 pm
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.
Sunshine - Moonlight - Good Times - Oolite
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6861
Joined: Wed Feb 28, 2007 7:54 am

Re: How to encourage more developers to be involved

Post by another_commander »

hiran wrote: Tue Jul 08, 2025 4:14 am
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.
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 436
Joined: Sun Feb 18, 2024 12:13 pm

Re: How to encourage more developers to be involved

Post by 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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6861
Joined: Wed Feb 28, 2007 7:54 am

Re: How to encourage more developers to be involved

Post by another_commander »

MrFlibble wrote: Tue Jul 08, 2025 8:31 am
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.
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 436
Joined: Sun Feb 18, 2024 12:13 pm

Re: How to encourage more developers to be involved

Post by MrFlibble »

another_commander wrote: Tue Jul 08, 2025 8:34 am
MrFlibble wrote: Tue Jul 08, 2025 8:31 am
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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6861
Joined: Wed Feb 28, 2007 7:54 am

Re: How to encourage more developers to be involved

Post by another_commander »

MrFlibble wrote: Tue Jul 08, 2025 9:11 am
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.
User avatar
hiran
Theorethicist
Posts: 2473
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: How to encourage more developers to be involved

Post by hiran »

another_commander wrote: Tue Jul 08, 2025 9:25 am
the external libs source modifications document
Where is that hosted?
Sunshine - Moonlight - Good Times - Oolite
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 436
Joined: Sun Feb 18, 2024 12:13 pm

Re: How to encourage more developers to be involved

Post by 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.
User avatar
hiran
Theorethicist
Posts: 2473
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: How to encourage more developers to be involved

Post by hiran »

MrFlibble wrote: Wed Jul 09, 2025 10:20 am
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?
Sunshine - Moonlight - Good Times - Oolite
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 436
Joined: Sun Feb 18, 2024 12:13 pm

Re: How to encourage more developers to be involved

Post by MrFlibble »

hiran wrote: Wed Jul 09, 2025 6:45 pm
MrFlibble wrote: Wed Jul 09, 2025 10:20 am
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'.
User avatar
hiran
Theorethicist
Posts: 2473
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: How to encourage more developers to be involved

Post by hiran »

MrFlibble wrote: Wed Jul 09, 2025 10:22 pm
hiran wrote: Wed Jul 09, 2025 6:45 pm
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.
Sunshine - Moonlight - Good Times - Oolite
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 436
Joined: Sun Feb 18, 2024 12:13 pm

Re: How to encourage more developers to be involved

Post by MrFlibble »

hiran wrote: Thu Jul 10, 2025 4:33 pm
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.
Post Reply