W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2020

[webrtc-insertable-streams] Piping capured audio to insertable stream from shell script (#41)

From: guest271314 via GitHub <sysbot+gh@w3.org>
Date: Wed, 12 Aug 2020 14:05:45 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-677721478-1597241144-sysbot+gh@w3.org>
guest271314 has just created a new issue for https://github.com/w3c/webrtc-insertable-streams:

== Piping capured audio to insertable stream from shell script ==
For the case of Chromium refusal to support capture of monitor devices am using Native Messaging and Native File System to write and read a file which is then parsed and set as `outputs` at `AudioWorkletProcessor.process()`, in pertinent part

`parec --raw -d alsa_output.pci-0000_00_1b.0.analog-stereo.monitor ../app/output`

which is read in main thread at browser. However, one issue is that Native File System currently cannot got a single handle on a file that is simultaneously being written to for the purpose of reading and writing at the same time, `DOMException`s will be thrown, and requires reading the entire file at each iteration to `slice()` from previous offset

          async function* fileStream() {
            while (true) {
              let fileHandle, fileBit, buffer;
                // if exception not thrown slice file from readOffset, handle exceptions
                // https://bugs.chromium.org/p/chromium/issues/detail?id=1084880
                // TODO: stream file being written at local filesystem
                // without reading entire file at each iteration before slice
                fileHandle = await dir.getFileHandle('output', {
                  create: false,
                fileBit = await fileHandle.getFile();
                if (fileBit) {
                  const slice = fileBit.slice(readOffset);
                  if (slice.size === 0 && done) {
                  if (slice.size > 0) {
                    buffer = await slice.arrayBuffer();
                    readOffset = readOffset + slice.size;
                    const u8_sab_view = new Uint8Array(memory.buffer);
                    const u8_file_view = new Uint8Array(buffer);
                    u8_sab_view.set(u8_file_view, writeOffset);
                    // accumulate  512 * 346 * 2 of data
                    if (
                      writeOffset > 512 * 346 * 2 &&
                      ac.state === 'suspended'
                    ) {
                      await ac.resume();
                    writeOffset = readOffset;
              } catch (err) {
                // handle DOMException
                // : A requested file or directory could not be found at the time an operation was processed.
                // : The requested file could not be read, typically due to permission problems that have occurred after a reference to a file was acquired.
                if (
                  err instanceof DOMException ||
                  err instanceof TypeError ||
                ) {
              } finally {
          for await (const _ of fileStream()) {
            if (done) break;

Does `opus-tools` have the capability to create an Opus bitstream that will support piping the output therefrom to the `writable` side of the insertable stream? That is, instead of writing the file and reading the file we can do something like

`parec --raw -d alsa_output.pci-0000_00_1b.0.analog-stereo.monitor | opusenc - - | opusenc <options_to_make_stdout_insertable_stream_writable_input> -` 

where we can then `write()` the output from the native shell script directly to an insertable stream, avoiding the need to re-read the same file just to get the current offset, or use `SharedArrayBuffer` to store the contents of the file in memory; we do not need to write a file at all, rather actually stream output from native application to `RTCPeerConnection`?

Please view or discuss this issue at https://github.com/w3c/webrtc-insertable-streams/issues/41 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 August 2020 14:05:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 12 August 2020 14:05:49 UTC