The WebSpeech specification at https://dvcs.w3.org/hg/speech-api/raw-file/tip/webspeechapi.html#dfn-ttspaused states that the paused state shall be independent of if contents of the utterance queue. I interpret the spec such that the following javascript snippet shall work.

speechSynthesis.pause();
setTimeout(speak_later, 1000);
      
function speak_later() {
    speechSynthesis.speak(new SpeechSynthesisUtterance("this is a test"));
    if (speechSynthesis.paused) {
        speechSynthesis.resume();
    }
}

The problem here is that resume is never called since paused is false and nothing will be spoken.

Some observations from the chrome implementation:
1. The paused state (as exposed to javascript) is triggered by platform callbacks which can only be updated on an utterance object. 
2. SpeechSynthesis::speak (in blink cpp code) actually overrides the paused state and forwards the speak call to the platform. The platform will still be in paused state so nothing will be spoken but the state exposed to javascript will be "not paused".

Maybe the paused state of the javascript object could be handled directly in the SpeechSynthesis instance in blink, i.e. updating the paused state in the calls to pause() and resume()? The paused event from the platform would just affect the paused javascript event on the related utterance and not affect the global paused state.

In addition to this each document has its own SpeechSynthesis instance on the renderer side but on the browser side there is a global singleton that serves all renderer instances. This could cause synchronization problems with respect to paused state since the browser has its own flag for this. For instance:

1. One page/tab call speechSynthesis.pause() which will put the TtsControllerImpl into paused state.
2. Another page/tab calls speechSynthesis.speak() but the utterance will be queued instead of directly spoken since the TtsControllerImpl is still in paused state. The second page may even check the speechSynthesis.paused flag but that will indicate a non paused state. The only thing that will work is to call speak first and then resume without checking the paused flag.

Have you had any problems with this? I am testing this on a custom platform implementation in our own product but most of the code except for the TtsPlatformImpl is the same and I think the same problems shall be present in Chrome.
 

The WebSpeech specification at https://dvcs.w3.org/hg/speech-api/raw-file/tip/webspeechapi.html#dfn-ttspaused states that the paused state shall be independent of the contents of the utterance queue. I interpret the spec such that the following javascript snippet shall work.

speechSynthesis.pause();
setTimeout(speak_later, 1000);
      
function speak_later() {
    speechSynthesis.speak(new SpeechSynthesisUtterance("this is a test"));
    if (speechSynthesis.paused) {
        speechSynthesis.resume();
    }
}

The problem here is that resume is never called since paused is false and nothing will be spoken.

Some observations from the chrome implementation:
1. The paused state (as exposed to javascript) is triggered by platform callbacks which can only be updated on an utterance object. 
2. SpeechSynthesis::speak (in blink cpp code) actually overrides the paused state and forwards the speak call to the platform. The platform will still be in paused state so nothing will be spoken but the state exposed to javascript will be "not paused".

Maybe the paused state of the javascript object could be handled directly in the SpeechSynthesis instance in blink, i.e. updating the paused state in the calls to pause() and resume()? The paused event from the platform would just affect the paused javascript event on the related utterance and not affect the global paused state.

In addition to this each document has its own SpeechSynthesis instance on the renderer side but on the browser side there is a global singleton that serves all renderer instances. This could cause synchronization problems with respect to paused state since the browser has its own flag for this. For instance:

1. One page/tab call speechSynthesis.pause() which will put the TtsControllerImpl into paused state.
2. Another page/tab calls speechSynthesis.speak() but the utterance will be queued instead of directly spoken since the TtsControllerImpl is still in paused state. The second page may even check the speechSynthesis.paused flag but that will indicate a non paused state. The only thing that will work is to call speak first and then resume without checking the paused flag.

Have you had any problems with this? I am testing this on a custom platform implementation in our own product but most of the code except for the TtsPlatformImpl is the same and I think the same problems shall be present in Chrome.