Strange clicking sounds in some phrases on high speech rate

[cyrmax]

Hello. Thanks for fixing speech slowdown on long phrases.
But in the last build there is another problem occured.
At speech rates faster than 85% (i mean VoiceOver speech rate) i hear strange clicking and glitching in some phrases endings.
I use Espeak TestFlight build 1.0 (11) with iOS 16.1 on IPhone 11.
System locale is Russia, voice language is also russian, variant Max.

I will attach screencast with demonstration. Sorry for the fact that demo video is in russian but i think that shouldn't be a problem.

espeak-glitching-demo.mp4

[LeonarddeR]

I can still reproduce this on higher speech rates. It somehow sounds like the last phoneme is duplicated. This is especially audible with the Dutch languages on words ending with the letter g, for example.

[cyrmax]

Yes, it sounds like last phoneme is repeated after some pause at the end of the phrase or even at the end of the word inside a phrase. For russian language it also works, especially if last word ends with consonants.

On 2/28/2023 10:29 AM, Leonard de Ruijter wrote: I can still reproduce this on higher speech rates. It somehow sounds like the last phoneme is duplicated. This is especially audible with the Dutch languages on words ending with the letter |g|, for example. — Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO37VZPHWDOW2CJ43HWJVF3WZWSNDANCNFSM6AAAAAAR7UY26I>. You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Best regards, Kirill Belousov aka Cyrmax, iOS and Python developer. ***@***.*** Telegram: @cyrmax Whatsapp: +7 (981) 862-01-82 VK:https://vk.com/cyrmax

[LeonarddeR]

@djphoenix Is this on your radar?

[jcsteh]

I think what might be happening is that some code somehow is pushing too many samples to the audio buffer. I saw this while I was reworking some of NVDA's eSpeak code for WASAPI. When Sonic is being used, eSpeak generates the audio at a slower rate, but then Sonic runs and shortens the buffer. If you accidentally read too many samples, you end up with some of the (original speed) audio at the end.

I know eSpeak has some bugs related to the events it passes to the callback, which is why this was happening in my code. The audio_position in the events doesn't seem to be correctly adjusted for Sonic, so you can't rely on those numbers not overrunning or underrunning the samples. However, from what I can see in the iOS code, you don't rely on eSpeak events, so this shouldn't be the cause. It seems the iOS code just pushes the number of samples passed as a callback argument, which should be correct. It mostly ignores the events currently (apart from logging), unless I'm missing something.

The only other thing I've spotted is that the iOS code calls espeak_ng_SetPhonemeEvents, but NVDA doesn't. I don't really understand why the iOS code does this though, as it doesn't seem to use them for anything other than logging. I also don't know if that could have anything to do with this or not.