Setting `sampleRate` to zero causes AudioContext creation to fail when compiling for WASM. Is that expected?

[michaelfiber]

When I transpile C99 projects to WASM, if I pass in a sampleRate of zero that gets passed as the sampleRate when the AudioContext is created which causes it to fail with the error DOMException: AudioContext constructor: Sample rate 0 is not in the range [8000, 192000].

Is that behavior expected? I think the comments around sampleRate suggest that setting to zero picks the device default but it seems that is not the case with WASM any more (I swear it used to be though).

I can simply try to avoid using sampleRate = 0 but wasn't sure if it made more sense to have logic in miniaudio to skip passing in a samplerate if the one provided is zero?

When I change this:

            var audioContextOptions = {};
            if (deviceType == window.miniaudio.device_type.playback) {
                audioContextOptions.sampleRate = sampleRate;
            }

to this:

            var audioContextOptions = {};
            if (deviceType == window.miniaudio.device_type.playback && sampleRate != 0) {
                audioContextOptions.sampleRate = sampleRate;
            }

the result is the AudioContext is created and uses its default sampleRate.

[mackron]

No, that's definitely not the intention. Indeed, a sample rate of 0 in the device config means the backend should use the default sample rate. I'll have a look at this. Thanks for reporting this one.

[michaelfiber]

Ok, cool, thank you!

For reference I am using miniaudio.h with raylib. I tested with the latest version of miniaudio.h and the latest raylib and I am compiling to WASM with the emsdk docker image so that should be the newest version too. I went back and dug up some of my old projects and it looks like the code has been updated pretty substantially. When I used miniaudio.h last for WASM it was a year ago but raylib was still using a version from 2021.

In the current version, inside ma_device_init__webaudio there's no reference to MA_DEFAULT_SAMPLE_RATE whereas the last time I used miniaudio.h the version raylib was using had a function called ma_device_init_by_type__webaudio and that sets the sampleRate to MA_DEFAULT_SAMPLE_RATE if the one it gets is zero. And the projects I built define an AudioContext with the default sample rate of 48000.

Based on the code I tweaked to get it working I am not using MA_USE_AUDIO_WORKLETS. I don't know how that is effected. When I tried compiling with that it created a number of other issues on my side that I couldn't get past.

[mackron]

Yes, I recently did some major refactoring to support AudioWorklets, so I've probably accidentally broken it then.

Out of curiosity, what were the issues you were encountering with MA_USE_AUDIO_WORKLETS? I have been pondering whether or not to enable that by default so was just curious to get a bit of a survey on possible issues to consider.

[michaelfiber]

It took me a bit to figure out the build flags required to get worklets going. I did end up getting that set up just now to try to test it but realized that it looks like it depends on SharedArrayBuffer which is disabled in FF and Chrome unless the right CORS settings are present on the server and I don't know if every place I plan to post is set up for that.

However now that I have it set up to build as long as I run chrome with --enable-features=SharedArrayBuffer I can tell that it does work. I'll have to investigate a bit more how many hurdles there are to ShareArrayBuffer being used where I plan to push the results.

[mackron]

Thanks. Interesting about SharedArrayBuffer. I'm not actually using that directly (at least, I can't find any reference to it in my code). That is probably an internal detail of the Emscripten abstraction which I have no control over. That's good to know though - might be worth me making a mention of that in the documentation.