WASM Throttle Block Implementation

[JuliDi]

I've been trying to make the throttle block a wasm-compatible. However, that was not successful yet.
Using web-time it is possible to replace the uses of std::time::Instant, but I could not figure out how to do the sleep.

There is already a wasm-compatible async sleep used in the flowgraph here

FutureSDR/src/runtime/flowgraph.rs

Line 217 in faef89b

gloo_timers::future::sleep(std::time::Duration::from_millis(200)).await;

but that Future does not implement Send and can therefore not be used in here

FutureSDR/src/blocks/throttle.rs

Line 98 in faef89b

Timer::after(Duration::from_millis(100)).await;

Any ideas how to make this work?

I am trying to just get some artificially generated data out of the flowgraph in wasm, but data seems to never reach the sink unless throttled. It does work when I compile it for linux.

Once I get that running I would like to also make the websocket sink wasm compatible using tokio-tungstenite-wasm. Working on a small demo that uses the slint GUI framework for plotting FutureSDR data. It works quite nicely when running slint in the browser and FutureSDR streaming the data from the "desktop" binary via websockets. But I'd like to have it self-contained in a single wasm application.

[bastibl]

I tried to add it but have no real test case at the moment, could you checkout the most recent commit?

At the moment, the wasm stuff is all single-threaded (i.e., non-Send) but can be spawned in a WebWorker. The block_on function was missing the compile switch, which should be added now. Extending also the wasm stuff to multi-threaded would be possible but that's quite a bit of work and one needs to dive in to shared array buffers.

[JuliDi]

Thank you, I will give it a try and report back.

[JuliDi]

I think what is still missing is a wasm compatible implementation of time. Now I'm getting time not implemented on this platform, presumably due to std::time::Instant being used. That one I was able to fix yesterday, so I can just rebase that branch and make a PR. Let's see how that works.

[bastibl]

Regarding your issue that something doesn't reach a block, that's often related to buffer history. A native block uses the circular buffer, where this is no issue. On wasm we use the slab buffer, which might need manual history/overlap configuration. See for example: https://github.com/FutureSDR/FutureSDR/blob/main/examples/zigbee/src/wasm_worker.rs#L100

[bastibl]

Buffers are complicated :-) For your FFT you have two options. You could either make the number of items that fit into the buffer a multiple of the FFT size (with 0 reserved items). In this case, you'll never come into the situation that only 500 or whatever items are left and you cannot proceed. Or you create the buffer with an arbitrary size but ensure that the copy-over mechanism (see blog post) makes sure that once fewer items than the FFT size are left in the buffer, the items will be copied over to the next buffer, which ensures that the block does not get stuck (i.e., getting called again and again with the remaining items that are not enough to proceed). This is configured with the reserved_items. The middle parameter, I always set to two.

[JuliDi]

I see, thanks for the explanation! Now it's more clear what impact the buffer has - and what is related to how the runtime itself works.
And on top of that the influence of the async runtime/WASM remains to be determined... ;)

[JuliDi]

Using connect!(fg, src > throttle [Slab::with_config(4,2,0)] mag [Slab::with_config(4,2,0)] snk); does indeed do the trick with my above example when I throttle to 1 sample per second. Now I can continue extending it to the FFT. Thanks!

[bastibl]

Arg, in that second I made a PR for your project xD

[JuliDi]

Oh now you're stealing all the fun! :D I've havent started working on the FFT part, I only confitmed that it's working with the single-sample sink, but I will check out your PR tomorrow. Thanks a lot!