support wasm32-unknown-unknown target

[jice-nospam]

This compile and runs fine with wasm32-unknown-unknown target, but doesn't produce any sound. Are you planning to support this target? Any idea why it doesn't work right now ?

[tomaka]

Supporting the wasm32-unknown-unknown is "ideologically" wrong. Playing/recording sounds requires some knowledge about the environment (like which OS is running), and unknown, as it says, doesn't give any information. We could support it by making assumptions, but sooner or later that will probably backfire.

Instead we could support something like wasm32-unknown-web or wasm32-unknown-node or something similar. There are some active debates in the Rust community about this topic in general.

Also note that the emscripten target should already work.

[jice-nospam]

This makes sense. I was referring to supporting the web platform without emscripten. There's no wasm32-unknown-web target yet so that's mainly what wasm32-unknown-unknown is used for. So I guess it's a wait-and-see subject for now.

[newpavlov]

It's possible to add wasm-bindgen and/or stdweb feature which users will have to enable in application crate to get support on wasm32-unknown-unknown, in a certain sense it will be an ersatz for the proper target triplet.

[nico-abram]

Does the emscripten target actually work, at the moment? I don't get any sound when running cargo web start --example beep --target wasm32-unknown-emscripten (On firefox)

I tried updating stdweb, but I still couldnt get it to work. As someone suggested here, I tried adding a feature that makes wasm32-unk-unk use the emcripten host instead of null, and, surprisingly, it seems to actually work.

That being said, updating stdweb basically raised 2 problems: set_timeout now has a 'static bound on its parameter, and event_loop no longer returns never (!).

The second problem is solved easily enough by adding a js exception and an unreachable to satisfy rust's type system. I think the reason for that change is that on wasm32-unknown-unknown event_loop does nothing and instantly returns.

The other problem is, I think, a bit more serious. I don't think the current casting using a Box I'm doing here is entirely sound, but it is the only thing I believe we can do without changing the API (Also, I don't think the lack of the static requirement on the older version makes things any better - The underlying browser API we're calling is the same, if anything I think the old binding was just plain wrong. So it's not like we're doing anything worse with my changes, I think)

Here's what I did: nico-abram@17f84ec

I haven't opened a PR since I don't think there's an agreement to use web apis on unk-unk under a feature flag (At least yet?) and because of the issues (Specially around 'static) I mentioned.

[nico-abram]

I was under the impression that the stdweb::web::set_timeout without the 'static on old stdweb was unsound, so I asked in the #wg-wasm channel in the official rust discord. Someone told me that it is, in fact, unsound. So I don't think my changes make the issue worse, only explicitly require us to use unsafe to pretend the closure that should be static is.

[mitchmindtree]

I just wanted to add that I'll be doing a deep dive into solving CPAL's web audio support soon as a part of an upcoming funded project which I can hopefully release some more info on soon. The plan is to investigate the feasibility of each of the possible web targets, decide exactly what targets cpal can/should support, ensure their implementation(s) are on par with the other platforms, write a decent usage guide and solicit some review and feedback from the community. The current plan is to be tackling this towards the beginning of Nov, while focusing on some preceding work like assisting with landing #301 and addressing #119, #279, #205 later this month. I'll post some more info soon.

[nico-abram]

Just dropping this here for anyone who missed it (Found it on the rust reddit) https://nannou.cc/posts/moss_grant_announce/

[ryanisaacg]

Just wanted to ask if there were any status updates for this?

[est31]

@ryanisaacg I'd definitely merge a PR that adds support for the web environment via stdweb and rust-bindgen.

[ryanisaacg]

@est31 I was more asking if there was anything new regarding @mitchmindtree's work on CPAL's web support through the nannou grant.

[mitchmindtree]

Not on this particular issue, but it's on my list. Sorry about the delay, there was a good couple of months delay in finalising the agreement with MOSS, but it's all sorted now. So far I've been focused on #354 and #359, from this point my plan is to merge #366, address #279 and #205, and then will start going over the web targets. I'll report back here when I have a worthy update.

[jice-nospam]

In case you need it, here is a crate that does native/web sound support using cpal (native) and stdweb : https://github.com/unrust/uni-snd

This is very low level, but provides stutter-free sound support on web. You can see it at work here :
http://viperconsole.ovh/?cart=carts/celeste.obe

There should be all the stuff you need to implement web support directly inside cpal

[dpeckett]

If it's of any interest I'm currently working on a wasm32/unknown cpal port as I need it urgently for one of my projects. I'm basing it off the emscripten backend but ported over to wasm-bindgen. I'm going to rip out the sketchy interval callback in favor of an event driven double buffered approach (eg. keep around a couple webaudio buffers and rotate them in and out as we receive playback finished events). Will report back if I make any major progress.

[mitchmindtree]

If it's of any interest

@dpeckett absolutely, I'd love to have you report back! Any assistance on this might free me up to hack on other pressing CPAL issues :)

[dpeckett]

@mitchmindtree I've put together a wasm-bindgen proof of concept: #372

[azriel91]

@dpeckett I've tried using #372 in a project, but chrome crashes with this:

Unable to write sample data into the audio context buffer: JsValue(TypeError: Failed to execute 'copyToChannel' on 'AudioBuffer': The provided ArrayBufferView value must not be shared.

The panic is from the following section:

for channel in 0..(config.channels as usize) {
    for i in 0..buffer_length {
        temporary_channel_buffer[i] =
            temporary_buffer[(config.channels as usize) * i + channel];
    }

    // panic is from this copy_to_channel / expect
    ctx_buffer
        .copy_to_channel(&mut temporary_channel_buffer, channel as i32)
        .expect("Unable to write sample data into the audio context buffer");
}

Do you understand what the message means? I've tried cloning both ctx_buffer and temporary_channel_buffer, but that + heaps of googling hasn't taken me far.

[chris-morgan]

Should #406 have closed this?

[mitchmindtree]

Yes thanks @chris-morgan, we have a few issues open and plan to write a short tutorial on using cpal with this target, but I think this can be closed now.