Building espeak-ng and pcaudiolib on mingw64

[another_commander]

Just managed to test espeak-ng now that I have the data folder too. From what I can see playback is already asynchronous here. It seems to work OK, although there are still a few rough points (e.g. setting voice to female does not actually change the gender until you select a language as well and also the female voice sounds like HAL9000's mother in law - needs a bit of massaging in the data files to make it a bit more pleasant). But the issue that is supposedly a blocker is not present from what I can see in my first tests.

[mcarans]

Just managed to test espeak-ng now that I have the data folder too. From what I can see playback is already asynchronous here. It seems to work OK, although there are still a few rough points (e.g. setting voice to female does not actually change the gender until you select a language as well and also the female voice sounds like HAL9000's mother in law - needs a bit of massaging in the data files to make it a bit more pleasant). But the issue that is supposedly a blocker is not present from what I can see in my first tests.

That sounds positive. I had checked my CMakeCache.txt for espeak-ng and it said async was on and also this merged PR from two years ago has a title "Copy audio buffer and send for playback without blocking, fixes Windows audio choppyness" which suggests that pcaudiolib on Windows should work without blocking.

I need to complete some changes as my pcaudiolib build is a bit hacked (I find messing with autotools stuff quite challenging and I need to get it to generate lines for the necessary Windows libraries which I had manually added to the resultant makefile). I will then make a PR for pcaudiolib which I hope they will merge.

If Linux and Windows both use espeak-ng then a modified data directory can be set up for both.

[another_commander]

I just realized what Commander_X was talking about. I reproduced the "hang". Do this to test:
1. Enable speech
2. Launch from station and come to a complete stop
3. Target the buoy directly in front of you. The voice will start saying "Identification system locked onto navigation buoy"
4. As soon as the speech starts, switch to aft view. You will find that the game will momentarily hang until the entire message is spoken and only then switch to aft view.

Yup, that's a little issue there. The library is definitely asynchronous but this will have to be investigated further.

[another_commander]

After some basic investigation, it appears that the function espeak_Cancel() does not work and this seems to be the reason for the block. If a message is being spoken and a [UNIVERSE stopSpeaking] call is made, then espeak_Cancel() gets executed and that's when the block happens.

Easiest way to test this is use the debug console command player.audioMessage("Insert a very long string here") and then execute immediately player.stopAudioMessage(). You will cause the game to block because this second command calls directly [UNIVERSE stopSpeaking], which in turn calls directly espeak_Cancel() inside espeak-ng. No other functions are called, so this has to be it.

Doing the same test on the standard distribution binaries immediately stops the message being played, as expected.

[mcarans]

After some basic investigation, it appears that the function espeak_Cancel() does not work and this seems to be the reason for the block. If a message is being spoken and a [UNIVERSE stopSpeaking] call is made, then espeak_Cancel() gets executed and that's when the block happens.

Easiest way to test this is use the debug console command player.audioMessage("Insert a very long string here") and then execute immediately player.stopAudioMessage(). You will cause the game to block because this second command calls directly [UNIVERSE stopSpeaking], which in turn calls directly espeak_Cancel() inside espeak-ng. No other functions are called, so this has to be it.

Doing the same test on the standard distribution binaries immediately stops the message being played, as expected.

However, running that test, I get the "Identification system locked onto navigation buoy" speech cut off mid sentence, and "aft view" immediately spoken and actioned, so I think my fork has inadvertently cured a bug which didn't affect me

Thanks for narrowing down the issue.

I guess that the problem lies in the xaudio2 implementation from the fact that Linux espeak-ng is fine. Cancelling has probably not been implemented or if it has, it is not working properly. I'll take a look. My fork is here if anyone else wants to take a peek: https://github.com/mcarans/pcaudiolib

EDIT: I can confirm cancelling is not implemented so I'll try to add something here:
https://github.com/mcarans/pcaudiolib/b ... 2.cpp#L149

[mcarans]

Easiest way to test this is use the debug console command player.audioMessage("Insert a very long string here") and then execute immediately player.stopAudioMessage(). You will cause the game to block because this second command calls directly [UNIVERSE stopSpeaking], which in turn calls directly espeak_Cancel() inside espeak-ng. No other functions are called, so this has to be it.

I haven't had time to test this myself. I'll try tomorrow, but if you want to have a go first, here is a link to the new dll: https://www.filemail.com/d/khhsyfuexolajzs

I added:

Code: Select all

int
xaudio2_object_flush(struct audio_object *object)
{
	struct xaudio2_object *self = to_xaudio2_object(object);

	self->source->Stop(0);
	self->source->FlushSourceBuffers();

	return S_OK;
}

[another_commander]

Crashes immediately as soon as I set Spoken Messages to ON in the game. Also the new dll is smaller in size than the previous, are we sure it was built the same way?

[mcarans]

Crashes immediately as soon as I set Spoken Messages to ON in the game. Also the new dll is smaller in size than the previous, are we sure it was built the same way?

I'll try to check today. I had tested it with espeak-ng on the command line and it worked there. I had excluded some Linux and Mac only stuff in the new one. I'll try reverting some things to see what causes the crash.
Edit:
Well all I needed to fix the crash was to check for source being null. Unfortunately that did not make any difference to the launch, target buoy, switch to aft test. So will need further investigation

[mcarans]

Here is the version of the library that has the flushing code and shouldn't crash. However, it doesn't seem to fix the problem which is odd.
https://www.filemail.com/d/udlauzkgnzzcqdu

I came across this issue about cancelling not working in espeak-ng on Windows 64 bit, but for that it was because it was playing in blocking mode. I will need to check if espeak-ng is working properly and asynchronously by making a simple test example to play sound and then cancel it.

I have checked in my version of pcaudiolib with fixes including the flush code here: https://github.com/mcarans/pcaudiolib

[mcarans]

I made tests for pcaudiolib and espeakng here: https://github.com/mcarans/AudioTest

The code I added to pcaudiolib's flush function worked. The problem seems to be with espeak-ng. I am investigating.

[mcarans]

After some basic investigation, it appears that the function espeak_Cancel() does not work and this seems to be the reason for the block. If a message is being spoken and a [UNIVERSE stopSpeaking] call is made, then espeak_Cancel() gets executed and that's when the block happens.

I have fixed this issue following the logic that people set out before in this PR part of which must have been changed later and this issue which basically suggests changing it back (although the author was probably unaware of the much earlier PR).

Here is updated espeak-ng (and libpcaudio although should be same as before):
https://www.filemail.com/d/icxelcrpnljuxyj

[another_commander]

It works!

[Commander_X]

It works!

Confirmed!
It even works with the most infernal test nobody mentioned yet, i.e., trying to change view while the message(s) from the clearance protocol are on (especially while reading the unending timestamp ).

[mcarans]

It works!

Confirmed!
It even works with the most infernal test nobody mentioned yet, i.e., trying to change view while the message(s) from the clearance protocol are on (especially while reading the unending timestamp ).

That's great news!

I have made PRs for pcaudiolib and espeak-ng:
https://github.com/espeak-ng/pcaudiolib/pull/34
https://github.com/espeak-ng/espeak-ng/pull/2288