easy-speech

easy-speech copied to clipboard

I'm currently running Chrome version 105.0.5195.102 on mac OS, and the resumeInfinity fix causes certain strings to hold up the queue. Disabling the fix seems to allow it to run correctly, with both shorter and longer strings.

I'm not sure on the reason, besides the fact that a quick pause and resume seems to prevent any 'end' events from firing, preventing the next item in the queue from starting. It also seemed to be more of an issue with slightly longer strings - I assume resumeInfinity only gets called when processing a longer string?

Some additional note on this... I've also noticed that the 'pause' functionality doesn't seem to work correctly in the above setup. I seems to still fire the 'end' event when paused (as if it's still reading the text silently).

Not sure if it's related to the above issue. I have a feeling this issue occurs with the browser's implementation of SpeechSynthesis - but figured it not pausing correctly and incorrectly firing the end event could be related to why the pause and resume functionality does the opposite (eg - it will still play, but won't correctly fire the 'end' event).

Hi @ellukesmith and thank you for reporting this!

What exactly means

causes certain strings to hold up the queue

Can you give me a short code example of your "queue" that I can use to reproduce on a few devices?

Thanks for the quick response @jankapunkt

The example that was failing for me was the following:

Childhood asthma and mental health
ANGELA MICHELETTO AND MICHELLE MACVEAN, AUSTRALIA, JANUARY 2022
What are the mental health impacts of asthma?
Children with asthma are at greater risk of experiencing adverse mental health and behavioural impacts (AIHW, 2020; McQuaid, Kopel & Nassau, 2001) and diminished health-related quality of life (HRQoL) than their healthy peers.

I was feeding each line above in as a separate block of text, and I found the second line (all in caps) would never fire an 'end' event. If I shortened that line, it would work - but for whatever reason that line would prevent the 'end' event from firing (so any additional lines I asked EasySpeech to 'speak' would never get read).

I managed to determine that the resumeInfinity function was causing the issue, specifically when it was calling the pause and resume one after the other. Adding a delay on the resume seemed to remedy the issue - but obviously causes a noticeable delay in the speech.

Let me know if you need anything else.

Thank you, this is interesting, since the resumeInfinity was specifically added to fix issues on Chrome with long texts. I will see if I can provide a fix that won't delay anything.

Hey @ellukesmith I finally got a mac under my hands and can confirm this. Interestingly this is not an issue in Safari and if you use the uppercase text in the demo then it first won't even play and when playing a second time it will spell out letter by letter.

I assume that chrome's tts implementation treats uppercase words as text to be spelled by each letter. This assumption is at least supported by the fact, that when I paste the following:

Angela MICHELETTO AND MICHELLE MACVEAN, AUSTRALIA, JANUARY 2022

Then Angela is spoken correctly, while the rest is spelled letter by letter. So my question to get back to you is now: does it work (including the correct event dispatched and follow-up texts working) if you enter the following texts:

Angela Micheletto and Michelle Macvean, Australia, January 2022

AND can you reproduce that resumeInfinity only becomes a problem, when an uppercase word is wiithin the text, for example:

Angela Micheletto and MICHELLE Macvean, Australia, January 2022

That's interesting - I didn't have that issue at all.

I've linked a Codepen example below, and all three examples never get to the second line of text. They also all play the text correctly, and there is no variation between how they're read based on it containing uppercase words.

https://codepen.io/drazic2012/pen/YzLrbeE

For reference, I'm on a 16" Macbook Pro, running macOS 10.15.6 and using Chrome version 105.0.5195.102.

Okay super interesting I tested your codepen @ellukesmith in MacOs 12.4 on chrome and reproduced it but here is the thing: the problem only occurs on the default English voice (Alex). If I use another voice (for example Daniel) then there is no issue at all.

Could you please give me a list of all voices where this occurs? You can easily test this on the demo page and switch voices:

https://jankapunkt.github.io/easy-speech/

It seems to be entirely related to the voices implementation and there seems to be currently no indicator that could help us to detect the voices that would cause this issue.

My proposal is to add a flag infiniteResume (which is default to true, based on determined factors in the init function) and allow users set it to false to prevent running with resumeInfinity.

This seems to be the most comprehensible tradeoff for now.

#156 is ready to review

@ellukesmith if this issue is still important to you and you are still working with this package I'd kindly ask you to review the PR and let me know if this at least helps you with these edge cases

Should be fixed with https://github.com/jankapunkt/easy-speech/releases/tag/v2.1.0

Feel free to reopen if the issue persists.