For information and discussion about Oolite.
https://bb.oolite.space/
Wondering: is it possible for voice output to reckognize it is taking too much time for the events coming in?
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 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).another_commander wrote: ↑Tue Jul 08, 2025 8:34 amI 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.
Code: Select all
Can't read data file: '/home/flibble/GNUstep/Applications/Oolite/oolite.app/Resources//espeak-data/intonations'Ah yes, the external libs source modifications document mentions this part for Windows: "MrFlibble wrote: ↑Tue Jul 08, 2025 9:11 amGreat... 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).
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.Code: Select all
Can't read data file: '/home/flibble/GNUstep/Applications/Oolite/oolite.app/Resources//espeak-data/intonations'
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.Where is that hosted?
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 wrote: ↑Wed Jul 09, 2025 10:20 amHere'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.
I agree. So what's the fix?hiran wrote: ↑Wed Jul 09, 2025 6:45 pmThis 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 wrote: ↑Wed Jul 09, 2025 10:20 amHere'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.
I do not have a real fix, just a hunch.MrFlibble wrote: ↑Wed Jul 09, 2025 10:22 pmI agree. So what's the fix?hiran wrote: ↑Wed Jul 09, 2025 6:45 pmThis 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'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'.
Agreed.hiran wrote: ↑Thu Jul 10, 2025 4:33 pmI 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.