native-messaging-nodejs VS native-messaging-espeak-ng

And/or control node and any other programming language from the browser using Native Messaging native-messaging-nodejs.

We can process asynchronous tasks without blocking reading stdin (e.g., full-duplex).

WHat do you mean by "contribute"? I download only the node executable using download-node-nightly-executable to run native-messaging-nodejs, servers, or whatever else I decide to experiement on - without downloading any packages.

I re-wrote the original code substituting using readSync for process.stdin.on('readable', () => {}) and including process.stdout._handle.setBlocking(true) and readFullSync function contributed by a Deno user https://github.com/guest271314/native-messaging-nodejs/blob/main/nm_nodejs.mjs. I wanted to a) get the input message (up to 1MB at a time) echo'ed back to the client; and b) get away from using process.stdin.on('readable', () => {}), rather use an approach that did not include event listeners; c) get away from using CommonJS and package.json and instead use Ecmascript modules without package.json.

If you want you can use a Node.js Native Messaging host https://github.com/guest271314/native-messaging-nodejs, Deno, QuickJS, txiki.js, Bun, C, C++, Python, WASI/WebAssembly or whatever language is built in, e.g., Bash.

I just fetch the nightly node executable, get rid of everything else in the archive, use .mjs extension for import to work without package.json, then I can connect to the host https://github.com/guest271314/native-messaging-nodejs, and start subprocesses, e.g., raw PCM streams, where stdout is streamed to the client (browser), e.g, https://github.com/guest271314/captureSystemAudio/blob/master/native_messaging/capture_system_audio/capture_system_audio_node.js.

Yes, utilizing Native Messaging https://github.com/guest271314/native-messaging-nodejs.

I'm just trying to use coqui-ai/TTS so I can stream speech synthesis output to the browser as I do with eSpeak NG https://github.com/guest271314/native-messaging-espeak-ng. I think the issue has been brought up before on GitHub. I have not read a solution. I am ready to try again if you can suggest a minimal build process.

You can use a Native Messaging host to run local code controlled from the browser. See native-messaging-deno for a general purpose and extensible solution and deno-server where Deno's serveTls is dynamically started to run a local application, stream stdout from the application to the browser, then stop the local server.

A single page Deno server can be found here https://github.com/guest271314/native-messaging-espeak-ng/blob/deno-server/local_server.js. I have used this source code // https://github.com/chcunningham/atomics-post-message/blob/main/server.js, renamed to server.msj modified to use Ecmascript Modules instead of CommonJS, e.g.,

I've already achieved the requirement multiple ways, already; from using Native Messaging https://github.com/guest271314/native-messaging-espeak-ng, to using GNU Core Utilities tail, to Deno.watchFs() https://github.com/guest271314/fs, et al., see captureSystemAudio. The one approach I have not yet achieved is compiling to Emscripten - with SSML support.

Create a self-signed certificate. If you are on Chromium or Chrome launch with --ignore-certificate-errors-spki-list=.... Read this https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/webtransport_server.py#L42-L72. This is how I use HTTPS for Deno and Node local servers and WebTransport https://github.com/guest271314/native-messaging-espeak-ng/tree/deno-server.

I use the source code for Deno's serveTls https://github.com/guest271314/native-messaging-espeak-ng/blob/deno-server/local_server.js and wrote a Web server module for QuickJS https://github.com/guest271314/webserver-c/tree/quickjs-webserver.

This https://github.com/guest271314/native-messaging-espeak-ng/tree/deno-server is what I do using Deno

I created https://github.com/guest271314/native-messaging-espeak-ng which provides a means to send text or SSML to the eSpeak NG speech synthesis engine and parse the generated WAV in the browser. That bypasses waiting around another N years for Google to prioritize Web Speech API, which I see no evidence of Google doing - except for its cloud service.

I merely read the article to see how the author was implementing "Text-to-Speech"; how they implemented "Text-to-Speech"; e.g., native-messaging-espeak-ng to overcome or avoid the multiple issues and limitations with using the specified Web Speech API in the browser.