...looking a bit further into the future... is there already an 'official'
proposal for a minimal buffer mixing API in the spirit of the
emscripten_webgl_* functions? A look at the SoLoud SDL static backend would
basically provide the minimal requirements (just an initialization function
with sample rate, format, channels, buffer size, and a callback function
which fills a memory chunk with sample
It might be easier to support WebAudio improvements in the future with such
a simplified audio API (I'm mainly thinking of audio worklets).
On Thursday, 5 April 2018 09:35:54 UTC+2, Floh wrote:
> I'll have a look at it over the next few days, if I can manage alone I'll
> provide a PR, otherwise I'll start with a github issue ;)
> On Thursday, 5 April 2018 05:36:47 UTC+2, Alon Zakai wrote:
>> Yeah, looks like the current code just supports U8 and S16. Probably
>> because the first things ported with it used those ;) I see that
>> BananaBread and Me&MyShadow both use S16...
>> Would be good to improve this.
>> On Wed, Apr 4, 2018 at 1:16 PM, Floh <flo...@gmail.com> wrote:
>>> Hi, I'm currently snooping around in library_sdl.js and wonder if there
>>> is a specific reason why the SDL Audio wrapper doesn't accept float32
>>> Here's my situation:
>>> - WebAudio AudioBuffers generally seem to have float32 samples (?)
>>> - the SoLoud library "SDL static" backend (which is best suited for
>>> emscripten) first tries to create an SDL audio context with float32
>>> samples, however this fails, so it falls back to signed 16-bit (see here:
>>> - however, in its audio callback, SoLoud also only accepts float32
>>> - ...so what happens is unfortunately this:
>>> (1) application provides float32 samples to SoLoud
>>> (2) SoLoud converts the float32 sample data to 16-bit integer before
>>> handing it to emscripten's SDL wrapper
>>> (3) emscripten converts the 16-bit integer samples back to float32
>>> (I think at least) before handing the sample data to WebAudio...
>>> It looks like supporting float32 samples in library_sdl.js wouldn't be
>>> too much work, unless I've overlooked something? Should I open a ticket for
>>> this? I might even find some time to tinker around with it and provide a
>>> pull request...
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.