-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use case: Streaming audio (to web platform) #307
Comments
Basically, what am considering is using this code https://github.com/guest271314/AudioWorkletStream/blob/shared-memory-audio-worklet-stream/index.html where
is substituted for
in WASI - and the system audio capture is performed in WASI - and the single |
The behavior of the core wasm Also, WASI is not currently implemented in browsers, so if your main use case is that you want to do something in a browser and can't due to limitations of browser APIs, WASI won't be a very efficient venue for addressing your use case. |
The use case is running WASI (any code) locally where STDOUT is written to shared memory. Yes, to overcome browser limitations is the goal. Native Messaging has limitations. Specifications and browser API's have limitations, some per specification, some per implementation decisions. Right now have no evidence to formulate a rational conclusion either way. Here, test code at least thousands of times before determine if the concept is viable or not, in brief according to the principles at https://gist.githubusercontent.com/guest271314/1fcb5d90799c48fdf34c68dd7f74a304/raw/c06235ae8ebb1ae20f0edea5e8bdc119f0897d9a/UseItBreakItFileBugsRequestFeaturesTestTestTestTestToThePointItBreaks.txt. There is no way to conclusively determine if a means of achieving a result is possible with testing. Am here asking the question to discern where to begin testing WASI for the specific use case described, as th What does WASI do? How is the goal of audio processing achieved using WASI? Or, is WASI a proof-of-concept right now? In which case wide range testing of use case should be consistent with the stated goal. |
The main use cases for WASI at present are in non-Web embeddings of WebAssembly. Current WASI APIs support features such as filesystem access, clocks, random numbers, and command-line arguments. Audio processing is a goal, and it has not yet been achieved. |
Well, local filesystem is a "non-Web embeddings of WebAssembly". The use case described includes filesystem access. What to do with the files WASI generates is not what asked. If you do not test your own goals when the use case is shared with you, then that guarantees it will not be achieved, unless the concept is in-house selective use-case tests, rather than testing the stated goals in all forms in order to find bugs before bugs are found in the wild. Do not do any begging, here. Ask questions directly. And since individuals and institutions are generally anti Free Speech, they would rather label, ban, censor than deal with facts and science, am already moving on to the next means of trying to achieve own goals. In the industries that purvey wares there is no waiting on any one else to do anything. Spare none immediate refutation of false claims and false advertising. If you are operating a closed-loop dialogue here, where input is to be reviewed for what we do not want, rather than how can we work together to achieve mutually beneficial goals, then your perspective is deliberately limited and incapable of being expanded beyond the closed-loop system that you have created, mathmatically proven by Godel nearly 100 years ago
Just don't write you are serious about WASI and audio processing if when a user in the wild brings a use case to your repository you say you have not achieved it yet. Am willing to test. Am not willing to wait on you, or any other individual or institution to do anything. The only way to achieve that goal is by testing. Read this very carefully
|
@sunfishcode Have made some progress after testing. Re-phrasing the question, given a shell
is it possible to do something like
and import that same Memory into JavaScript for reading during the write? |
The specifics of how wasm and JS language features interact are out of scope for WASI. This forum is for WASI development, so your question is off topic. |
@sunfishcode FWIW a formal proposal https://bugs.chromium.org/p/chromium/issues/detail?id=1115640. Note that WASI mission statement and mandate is not out of scope there, as the native code or shell script can be WASI implementation of |
Charter https://github.com/WebAssembly/WASI/blob/master/Charter.md#webassembly-system-interface-subgroup-charter
includes the goal
System architechture 32-bit, OS Linux.
The use case is capturing system audio output, which is currently not possible at Chromium browser without using
pavucontrol
or other workaround for https://chromium-review.googlesource.com/c/chromium/src/+/1064373/.Created one of several workarounds using Native Messaging. The problem is there is no simple way to stream output from
bash
to JavaScript.Given execution of a
bash
scriptparec--raw -d alsa_output.pci-0000_00_1b.0.analog-stereo.monitor | split -d -b 512 --additional-suffix=".s16le" --suffix-length=8 - ../app/""
AudioWorkletProcessor
executesprocess()
approximately 344-384 times per second. Am able to parse the files toFloat32Array
s, however,process()
executes faster than writing and reading the 512 byte files to local filesystem, leading to no data being available due to all files being read (and deleted) while capturing and writing is still ongoing; and the message propagation to and from Native Messaging (which is text based) also takes time, e.g., race-conditions, in briefNative Messaging extension code where
externalPort
is a port to an arbitrary web pageNodejs Native Messaging host
Part of JavaScript on the web page that reads the files written to local filesystem by
bash
script (parec
andsplit
-split
is used because it is not currently possible to read a file while being written at local file system using Native File System without reading the entire file). TheReadableStream
is transferred toAudioWorkletProcessor
where read andFloat32Array
are pared from the raw data.Craeted a
WebAssembly.Memory
instance for a version of theAudioWorklet
that is used to output audio, however,Memory.grow()
has issues re JavaScript andTypedArray
s, so we cannot being at 1 page, then grow theSharedArrayBuffer
to suit the use case of capturing an arbitrary amount of audio data tc39/test262#2719, we need to allocate N amount of memory beforehand.Is it possible to use WASI to write the stream directly to a single
Memory
, grow when necessary in WASI/WebAssembly then read that memory to produce audio?The text was updated successfully, but these errors were encountered: