GoogleNetworkSpeechSynthesis VS persistent-serviceworker

If you want you can use Google's TTS service without Web Speech API with a proxy, see GoogleNetworkSpeechSynthesis. I made a feature request for Google to release the source code as FOSS Re: Issue 263510047: Release TTS and STT source code and Google voices as FOSS so we don't have to make external requests just to use Web Speech API.

I requested to Google to Release TTS and STT source code and Google voices as FOSS which you can request over the network here GoogleNetworkSpeechSynthesis. Those are the voices Google Chrome uses for Web Speech API. Feel free to chime on the feature request in in support of Google releasing the source code of its network-based cloud service (that google uses for Web Speech API implementation) TTS and SST code as FOSS.

Technically you can use Google API key shipped in the browser see guest271314/ GoogleNetworkSpeechSynthesis . No need to sign up for a Google account to use this. I don't think Google's TTS is related to "AI".

This is how you can make the request yourself GoogleNetworkSpeechSynthesis.

If anybody want to build a TTS "module" or "component" that accepts and processes SSML input, and that the user can control - to an appreciable degree - on the front-end you can play around with this https://github.com/guest271314/GoogleNetworkSpeechSynthesis. (Makes an external request). Have fun!

It is possible to use Google Network Speech Synthesis service "free of charge", see GoogleNetworkSpeechSynthesis. On Chrome if you use Google voices with SpeechSynthesisUtterance() and window.speechSynthesis.speak() you are doing that anyway.

I implemented SSML parsing in JavaScript by hand for Web Speech API per SSML specification https://github.com/guest271314/SSMLParser, where the Web Speech API nor Firefox nor Chrome or Chromium browsers (Google does implement SSML parsing as a service https://github.com/guest271314/GoogleNetworkSpeechSynthesis) have implemented SSML parsing.

FYI when Google voices are used on Chrome or Chromium-based browsers the browser also makes a remote request, see https://github.com/guest271314/GoogleNetworkSpeechSynthesis.

How is processing SSML an attack vector? Google provides that capability as a service - with embedded limitations on character input that are not specified. This can and should be implemented in the browser - without making an external request; native-messaging-espeak-ng, GoogleNetworkSpeechSynthesis.

Here you go persistent-serviceworker.

The ServiceWorker becoming inactive in 5 minutes per MV3 is a debacle. Workarounds exist and the code to implement keeping the ServiceWorker persistent, e.g., to stream live radio station from the ServiceWorker to the client winds up not saving any resources - we have to keep something running to keep the service worker running. You would be hard-pressed to count how many issues in the wild have been filed in multiple source code repositories just on that lack of functionality - for years now, e.g., Need help to understand and use this #2.

There are workarounds which involve using an iframe https://github.com/guest271314/persistent-serviceworker/tree/main/chromium_extension_web_accessible_resources_iframe_message_event or window.open() https://github.com/guest271314/sw-transfer-stream or and offscreen document https://github.com/guest271314/offscreen-webrtc with WebRTC - however that involves loading an entire HTML document, and each has its own deficienfies - with all of the Window features that we do not really need just to transfer data between the Web page I have control of and the ServiceWorker I have control of.

One approach for your requirement is to append an iframe with src set to an HTML document listed in "web_accessible_resources" to an arbitrary document and use postMessage() from the Web page to the iframe, then from the iframe to the MV3 ServiceWorker, see https://github.com/guest271314/persistent-serviceworker/tree/main/chromium_extension_web_accessible_resources_iframe_message_event.

See https://github.com/guest271314/persistent-serviceworker

Yes, it is possible to keep an extension or non-extension ServiceWorker persistent, active indefinitely https://github.com/guest271314/persistent-serviceworker.

If you host the HTML for and use "web_accessible_resources" in manifest.json the </code> can communicate directly with MV3 <code>ServiceWorker</code>. </p> <p>To keep MV3 <code>ServiceWorker</code> persistent see <a href="https://github.com/guest271314/persistent-serviceworker">https://github.com/guest271314/persistent-serviceworker</a>.</p> </div>

I utilize "web_accessible_resources" with an , where chrome.* API's are exposed, and does not become inactive.

Some workarounds to keep MV3 ServiceWorker active Persistent ServiceWorker.