Re: Why no AUDIO_F32 support in the SDL Audio wrapper

[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

[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: help with converting library to JS

[Floh]

PS:

I found out that using Ubuntu emescripten package also isn't the best idea 
> so now i am download it from git.
>

Best option is to use the official emsdk as described 
here: 
https://kripken.github.io/emscripten-site/docs/getting_started/downloads.html


-- 
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: help with converting library to JS

[Floh]

> So i should use this : https://github.com/GSL-for-JS/gsl-js or standar 
GSL?

I would try standard GLS, and check whether gls-js was heavily modified to 
make it work on emscripten, but since it's mostly simple C code I guess it 
wasn't)

> And using Ubuntu subsystem for Win is really bad idea for dealing with 
this problem?

No it's fine, only problem I know of is that file operations are fairly 
slow through the WSL layer.

> And i am sorry that i am taking your time but i am not so C person, i 
rather use higer level programing languages.

It's more a build system problem than a language problem, it's always a 
build system problem in the C/C++ world ;)

On Thursday, 5 April 2018 10:23:42 UTC+2, Peter wrote:
>
> Thank you for your replay. 
> I found out that using Ubuntu emescripten package also isn't the best idea 
> so now i am download it from git.
>
> About GSL
> So i should use this : https://github.com/GSL-for-JS/gsl-js or standar 
> GSL?
>
> And using Ubuntu subsystem for Win is really bad idea for dealing with 
> this problem?
>
> And i am sorry that i am taking your time but i am not so C person, i 
> rather use higer level programing languages.
>
>
>

-- 
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: help with converting library to JS

[Peter]

>Wait, here is the problem, a big fat FORTRAN source file:
>
>
https://github.com/libamtrack/library/blob/master/thirdparty/cernlib/CERNLIBFUNS.f
>
>I don't think it's possible to get that through emscripten.

So I have to remove it with all dependencies to this, right?

-- 
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: help with converting library to JS

[Floh]

...maybe a Fortran to C converter like this: http://cci.lbl.gov/fable/ 
would be solution..., but it might not be a trivial thing to do...

On Thursday, 5 April 2018 10:16:57 UTC+2, Floh wrote:
>
> Wait, here is the problem, a big fat FORTRAN source file:
>
>
> https://github.com/libamtrack/library/blob/master/thirdparty/cernlib/CERNLIBFUNS.f
>
> I don't think it's possible to get that through emscripten.
>
> On Thursday, 5 April 2018 10:12:12 UTC+2, Floh wrote:
>>
>> (1) I would try to start with a pure GSL source repo, not the gsl-js repo 
>> (this provides a precompiled .js blob callable from Javascript, but it 
>> looks like you need GSL as a normal C library to be compiled with 
>> libamtrack.
>>
>> (2) the main problem here which I don't understand is why it's trying to 
>> call gfortran, from looking over the repositories I haven't seen any 
>> Fortran sources (which would be a show stopper), all I've seen is C headers 
>> and sources (which is good)
>>
>> If I would tackle the problem I would probably throw away all the 
>> autoconf stuff, put all sources (GSL and libamtrack) into a common project 
>> directory, and write a simplest-possible cmake file with hardwired config 
>> for emscripten which compiles a static library. But YMMV of course :)
>>
>> On Thursday, 5 April 2018 08:44:06 UTC+2, Peter wrote:
>>>
>>> Hello, I am working on application to provide easy way to use this 
>>> library:
>>> https://github.com/libamtrack/library
>>>
>>> generally the main purpose is provide it as easy to use web application.
>>> So lately I am trying to convert it to JS using Emscripten.
>>>
>>> I have to problems:
>>> 1. GSL
>>> I found this: https://github.com/Planeshifter/gsl-js
>>> the emmake make for this is generrly sucessful but I don't know how to 
>>> use it during building main lib
>>>  but genrally during emmake I get error:
>>> fatal error: 'gsl/gsl_integration.h' file not found
>>> #include 
>>>
>>> 2.
>>> make:
>>> libtool: link: gfortran -shared  -fPIC  
>>> .libs/libcernlibfuns_la-AT_CernlibFuns.o .libs/CERNLIBFUNS.o   -lgsl 
>>> -lgslcblas -lm  -g -O2   -Wl,-soname -Wl,libcernlibfuns.so.0 -o 
>>> .libs/libcernlibfuns.so.0.0.0
>>> libtool: link: (cd ".libs" && rm -f "libcernlibfuns.so.0" && ln -s 
>>> "libcernlibfuns.so.0.0.0" "libcernlibfuns.so.0")
>>>
>>> emmake make:
>>> libtool: link: gfortran -shared  -fPIC  
>>> .libs/libcernlibfuns_la-AT_CernlibFuns.o .libs/CERNLIBFUNS.o   -lgsl 
>>> -lgslcblas -lm  -g -O2   -Wl,-soname -Wl,libcernlibfuns.so.0 -o 
>>> .libs/libcernlibfuns.so.0.0.0
>>> .libs/libcernlibfuns_la-AT_CernlibFuns.o: file not recognized: File 
>>> format not recognized
>>> collect2: error: ld returned 1 exit status
>>>
>>> I know that probably its really easy to figure it out how to do it, but 
>>> I spend last week trying to find some solution and nothing :(
>>> If someone would give me a hint where to start it would be really greate.
>>> Thank you for you time,
>>> peter
>>>
>>>
>>>
>>>

-- 
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: help with converting library to JS

[Peter]

Thank you for your replay. 
I found out that using Ubuntu emescripten package also isn't the best idea 
so now i am download it from git.

About GSL
So i should use this : https://github.com/GSL-for-JS/gsl-js or standar GSL?

And using Ubuntu subsystem for Win is really bad idea for dealing with this 
problem?

And i am sorry that i am taking your time but i am not so C person, i 
rather use higer level programing languages.


-- 
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: help with converting library to JS

[Floh]

Wait, here is the problem, a big fat FORTRAN source file:

https://github.com/libamtrack/library/blob/master/thirdparty/cernlib/CERNLIBFUNS.f

I don't think it's possible to get that through emscripten.

On Thursday, 5 April 2018 10:12:12 UTC+2, Floh wrote:
>
> (1) I would try to start with a pure GSL source repo, not the gsl-js repo 
> (this provides a precompiled .js blob callable from Javascript, but it 
> looks like you need GSL as a normal C library to be compiled with 
> libamtrack.
>
> (2) the main problem here which I don't understand is why it's trying to 
> call gfortran, from looking over the repositories I haven't seen any 
> Fortran sources (which would be a show stopper), all I've seen is C headers 
> and sources (which is good)
>
> If I would tackle the problem I would probably throw away all the autoconf 
> stuff, put all sources (GSL and libamtrack) into a common project 
> directory, and write a simplest-possible cmake file with hardwired config 
> for emscripten which compiles a static library. But YMMV of course :)
>
> On Thursday, 5 April 2018 08:44:06 UTC+2, Peter wrote:
>>
>> Hello, I am working on application to provide easy way to use this 
>> library:
>> https://github.com/libamtrack/library
>>
>> generally the main purpose is provide it as easy to use web application.
>> So lately I am trying to convert it to JS using Emscripten.
>>
>> I have to problems:
>> 1. GSL
>> I found this: https://github.com/Planeshifter/gsl-js
>> the emmake make for this is generrly sucessful but I don't know how to 
>> use it during building main lib
>>  but genrally during emmake I get error:
>> fatal error: 'gsl/gsl_integration.h' file not found
>> #include 
>>
>> 2.
>> make:
>> libtool: link: gfortran -shared  -fPIC  
>> .libs/libcernlibfuns_la-AT_CernlibFuns.o .libs/CERNLIBFUNS.o   -lgsl 
>> -lgslcblas -lm  -g -O2   -Wl,-soname -Wl,libcernlibfuns.so.0 -o 
>> .libs/libcernlibfuns.so.0.0.0
>> libtool: link: (cd ".libs" && rm -f "libcernlibfuns.so.0" && ln -s 
>> "libcernlibfuns.so.0.0.0" "libcernlibfuns.so.0")
>>
>> emmake make:
>> libtool: link: gfortran -shared  -fPIC  
>> .libs/libcernlibfuns_la-AT_CernlibFuns.o .libs/CERNLIBFUNS.o   -lgsl 
>> -lgslcblas -lm  -g -O2   -Wl,-soname -Wl,libcernlibfuns.so.0 -o 
>> .libs/libcernlibfuns.so.0.0.0
>> .libs/libcernlibfuns_la-AT_CernlibFuns.o: file not recognized: File 
>> format not recognized
>> collect2: error: ld returned 1 exit status
>>
>> I know that probably its really easy to figure it out how to do it, but I 
>> spend last week trying to find some solution and nothing :(
>> If someone would give me a hint where to start it would be really greate.
>> Thank you for you time,
>> peter
>>
>>
>>
>>

-- 
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: help with converting library to JS

[Floh]

(1) I would try to start with a pure GSL source repo, not the gsl-js repo 
(this provides a precompiled .js blob callable from Javascript, but it 
looks like you need GSL as a normal C library to be compiled with 
libamtrack.

(2) the main problem here which I don't understand is why it's trying to 
call gfortran, from looking over the repositories I haven't seen any 
Fortran sources (which would be a show stopper), all I've seen is C headers 
and sources (which is good)

If I would tackle the problem I would probably throw away all the autoconf 
stuff, put all sources (GSL and libamtrack) into a common project 
directory, and write a simplest-possible cmake file with hardwired config 
for emscripten which compiles a static library. But YMMV of course :)

On Thursday, 5 April 2018 08:44:06 UTC+2, Peter wrote:
>
> Hello, I am working on application to provide easy way to use this library:
> https://github.com/libamtrack/library
>
> generally the main purpose is provide it as easy to use web application.
> So lately I am trying to convert it to JS using Emscripten.
>
> I have to problems:
> 1. GSL
> I found this: https://github.com/Planeshifter/gsl-js
> the emmake make for this is generrly sucessful but I don't know how to use 
> it during building main lib
>  but genrally during emmake I get error:
> fatal error: 'gsl/gsl_integration.h' file not found
> #include 
>
> 2.
> make:
> libtool: link: gfortran -shared  -fPIC  
> .libs/libcernlibfuns_la-AT_CernlibFuns.o .libs/CERNLIBFUNS.o   -lgsl 
> -lgslcblas -lm  -g -O2   -Wl,-soname -Wl,libcernlibfuns.so.0 -o 
> .libs/libcernlibfuns.so.0.0.0
> libtool: link: (cd ".libs" && rm -f "libcernlibfuns.so.0" && ln -s 
> "libcernlibfuns.so.0.0.0" "libcernlibfuns.so.0")
>
> emmake make:
> libtool: link: gfortran -shared  -fPIC  
> .libs/libcernlibfuns_la-AT_CernlibFuns.o .libs/CERNLIBFUNS.o   -lgsl 
> -lgslcblas -lm  -g -O2   -Wl,-soname -Wl,libcernlibfuns.so.0 -o 
> .libs/libcernlibfuns.so.0.0.0
> .libs/libcernlibfuns_la-AT_CernlibFuns.o: file not recognized: File format 
> not recognized
> collect2: error: ld returned 1 exit status
>
> I know that probably its really easy to figure it out how to do it, but I 
> spend last week trying to find some solution and nothing :(
> If someone would give me a hint where to start it would be really greate.
> Thank you for you time,
> peter
>
>
>
>

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

[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

[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

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

help with converting library to JS

[Peter]

Hello, I am working on application to provide easy way to use this library:
https://github.com/libamtrack/library

generally the main purpose is provide it as easy to use web application.
So lately I am trying to convert it to JS using Emscripten.

I have to problems:
1. GSL
I found this: https://github.com/Planeshifter/gsl-js
the emmake make for this is generrly sucessful but I don't know how to use 
it during building main lib
 but genrally during emmake I get error:
fatal error: 'gsl/gsl_integration.h' file not found
#include 

2.
make:
libtool: link: gfortran -shared  -fPIC  
.libs/libcernlibfuns_la-AT_CernlibFuns.o .libs/CERNLIBFUNS.o   -lgsl 
-lgslcblas -lm  -g -O2   -Wl,-soname -Wl,libcernlibfuns.so.0 -o 
.libs/libcernlibfuns.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libcernlibfuns.so.0" && ln -s 
"libcernlibfuns.so.0.0.0" "libcernlibfuns.so.0")

emmake make:
libtool: link: gfortran -shared  -fPIC  
.libs/libcernlibfuns_la-AT_CernlibFuns.o .libs/CERNLIBFUNS.o   -lgsl 
-lgslcblas -lm  -g -O2   -Wl,-soname -Wl,libcernlibfuns.so.0 -o 
.libs/libcernlibfuns.so.0.0.0
.libs/libcernlibfuns_la-AT_CernlibFuns.o: file not recognized: File format 
not recognized
collect2: error: ld returned 1 exit status

I know that probably its really easy to figure it out how to do it, but I 
spend last week trying to find some solution and nothing :(
If someone would give me a hint where to start it would be really greate.
Thank you for you time,
peter



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

[Александр Гурьянов]

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.