Re: Why no AUDIO_F32 support in the SDL Audio wrapper

2018-04-05 Thread Floh 
Alright, here's an initial PR for a first 
review: https://github.com/kripken/emscripten/pull/6429

The changes are minimal, but I think all the required stuff is in. I'd need 
some advice how to test this further to make sure there are no regressions 
in existing code.

Cheers!
-Floh

On Thursday, 5 April 2018 17:48:36 UTC+2, Alon Zakai wrote:
>
> I remember some general discussions in the far past, but nothing in recent 
> years (and probably things changed since then on the Web API side). That's 
> a good idea though.
>
> On Thu, Apr 5, 2018 at 12:43 AM, Floh  
> wrote:
>
>> ...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 data): 
>> https://github.com/jarikomppa/soloud/blob/master/src/backend/sdl_static/soloud_sdl_static.cpp
>>
>> It might be easier to support WebAudio improvements in the future with 
>> such a simplified audio API (I'm mainly thinking of audio worklets).
>>
>> Cheers!
>> -Floh.
>>
>> 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 ;)
>>>
>>> Cheers!
>>> -Floh.
>>>
>>> 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 both use S16...

 Would be good to improve this.

 On Wed, Apr 4, 2018 at 1:16 PM, Floh  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 
> samples?
>
> 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:
> https://github.com/jarikomppa/soloud/blob/3cd9b4bfa96a1e4b468dac34643a495fcaa77b0f/src/backend/sdl_static/soloud_sdl_static.cpp#L74
>  
> )
>
> - however, in its audio callback, SoLoud also only accepts float32 
> samples...
>
> - ...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...
>
> Cheers!
> -Floh.
>
> -- 
> 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 
>> "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 
"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.

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

2018-04-05 Thread Alon Zakai 
I remember some general discussions in the far past, but nothing in recent
years (and probably things changed since then on the Web API side). That's
a good idea though.

On Thu, Apr 5, 2018 at 12:43 AM, Floh  wrote:

> ...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 data): https://github.com/
> jarikomppa/soloud/blob/master/src/backend/sdl_static/soloud_sdl_static.cpp
>
> It might be easier to support WebAudio improvements in the future with
> such a simplified audio API (I'm mainly thinking of audio worklets).
>
> Cheers!
> -Floh.
>
> 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 ;)
>>
>> Cheers!
>> -Floh.
>>
>> 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 both use S16...
>>>
>>> Would be good to improve this.
>>>
>>> On Wed, Apr 4, 2018 at 1:16 PM, Floh  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
 samples?

 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:
 https://github.com/jarikomppa/soloud/blob/3cd9b4bfa96a1
 e4b468dac34643a495fcaa77b0f/src/backend/sdl_static/soloud_
 sdl_static.cpp#L74 )

 - however, in its audio callback, SoLoud also only accepts float32
 samples...

 - ...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...

 Cheers!
 -Floh.

 --
 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
> "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 
"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.

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

2018-04-05 Thread Floh 
...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 
data): 
https://github.com/jarikomppa/soloud/blob/master/src/backend/sdl_static/soloud_sdl_static.cpp

It might be easier to support WebAudio improvements in the future with such 
a simplified audio API (I'm mainly thinking of audio worklets).

Cheers!
-Floh.

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 ;)
>
> Cheers!
> -Floh.
>
> 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 both use S16...
>>
>> Would be good to improve this.
>>
>> On Wed, Apr 4, 2018 at 1:16 PM, Floh  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 
>>> samples?
>>>
>>> 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:
>>> https://github.com/jarikomppa/soloud/blob/3cd9b4bfa96a1e4b468dac34643a495fcaa77b0f/src/backend/sdl_static/soloud_sdl_static.cpp#L74
>>>  
>>> )
>>>
>>> - however, in its audio callback, SoLoud also only accepts float32 
>>> samples...
>>>
>>> - ...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...
>>>
>>> Cheers!
>>> -Floh.
>>>
>>> -- 
>>> 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 
"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.

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

2018-04-05 Thread Floh 
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 ;)

Cheers!
-Floh.

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 both use S16...
>
> Would be good to improve this.
>
> On Wed, Apr 4, 2018 at 1:16 PM, Floh  
> 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 
>> samples?
>>
>> 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:
>> https://github.com/jarikomppa/soloud/blob/3cd9b4bfa96a1e4b468dac34643a495fcaa77b0f/src/backend/sdl_static/soloud_sdl_static.cpp#L74
>>  
>> )
>>
>> - however, in its audio callback, SoLoud also only accepts float32 
>> samples...
>>
>> - ...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...
>>
>> Cheers!
>> -Floh.
>>
>> -- 
>> 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 
"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.

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

2018-04-05 Thread Floh 
I'm not sure if it would result in a measurable performance boost, but it 
would be one lossy conversion step less :)

On Thursday, 5 April 2018 08:02:28 UTC+2, caiiiycuk wrote:
>
> Wow, is it mean that if changes will be made, then we can have a 
> little performance boost if use float32 samples? 
>
> 2018-04-05 10:36 GMT+07:00 Alon Zakai : 
> > 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 both use S16... 
> > 
> > Would be good to improve this. 
> > 
> > On Wed, Apr 4, 2018 at 1:16 PM, Floh  
> 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 
> samples? 
> >> 
> >> 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:
> https://github.com/jarikomppa/soloud/blob/3cd9b4bfa96a1e4b468dac34643a495fcaa77b0f/src/backend/sdl_static/soloud_sdl_static.cpp#L74
>  
> >> ) 
> >> 
> >> - however, in its audio callback, SoLoud also only accepts float32 
> >> samples... 
> >> 
> >> - ...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... 
> >> 
> >> Cheers! 
> >> -Floh. 
> >> 
> >> -- 
> >> 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 
> > "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 
"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.

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

2018-04-05 Thread Александр Гурьянов 
Wow, is it mean that if changes will be made, then we can have a
little performance boost if use float32 samples?

2018-04-05 10:36 GMT+07:00 Alon Zakai :
> 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 both use S16...
>
> Would be good to improve this.
>
> On Wed, Apr 4, 2018 at 1:16 PM, Floh  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 samples?
>>
>> 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:https://github.com/jarikomppa/soloud/blob/3cd9b4bfa96a1e4b468dac34643a495fcaa77b0f/src/backend/sdl_static/soloud_sdl_static.cpp#L74
>> )
>>
>> - however, in its audio callback, SoLoud also only accepts float32
>> samples...
>>
>> - ...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...
>>
>> Cheers!
>> -Floh.
>>
>> --
>> 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
> "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 
"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.

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

2018-04-04 Thread Alon Zakai 
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 both use S16...

Would be good to improve this.

On Wed, Apr 4, 2018 at 1:16 PM, Floh  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 samples?
>
> 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:
> https://github.com/jarikomppa/soloud/blob/3cd9b4bfa96a1e4b468dac34643a49
> 5fcaa77b0f/src/backend/sdl_static/soloud_sdl_static.cpp#L74 )
>
> - however, in its audio callback, SoLoud also only accepts float32
> samples...
>
> - ...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...
>
> Cheers!
> -Floh.
>
> --
> 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 
"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.