persistent-serviceworker VS captureSystemAudio

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.

Synchronous. Though non-blocking when we read the message from the browser, execute the command, then stream data output from the local application to the browser piped from QuickJS std.popen(), capture_system_audio.js

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.

Sure, see https://github.com/guest271314/captureSystemAudio/blob/master/native_messaging/capture_system_audio/background.js, in pertinent part

This is my second time writing C source code capture_system_audio.c. I got a lot of help doing that, too . I basically implemented the same Native Messaging host algorithm in C, C++, Python, WASI/WebAssembly, and JavaScript (Node.js, QuickJS) which is the programming language I write code most using.

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.

Technically I can just serve the raw data as long as the server is capable of opening creating sub-processes, e.g., using EventSource https://plnkr.co/edit/qX5tepJ38BuDOSZj?preview, in which case I would just need to convert this https://github.com/guest271314/captureSystemAudio/blob/master/native_messaging/capture_system_audio/capture_system_audio.c to accept GET request, read the URL, and send the named event stream to the client.

Chromium and Chrome refuses to capture monitor devices on Linux. Read this https://github.com/edisionnano/Screenshare-with-audio-on-Discord-with-Linux README and the README at https://github.com/guest271314/captureSystemAudio very carefully. At best you can capture tab audio, not whatever is output to speakears and headphones, in spite of the systemAudio constraints, which is poorly named, and actually misleading.

How is capturing speechSynthesis.speak() a security vector https://github.com/guest271314/captureSystemAudio?

Capture audio output to speakers or headphones to MP3 or Opus in WebM https://github.com/guest271314/captureSystemAudio/tree/master/native_messaging/capture_system_audio

An example of using Native Messaging to capture "What-U-Hear", sound output to speakers and headphone, launching native GUI's https://github.com/guest271314/captureSystemAudio/tree/master/native_messaging/capture_system_audio; an adapter for espeak-ng so we can capture the output of speech synthesis engine and stream output to the browser https://github.com/guest271314/native-messaging-espeak-ng.