Re: help with converting library to JS

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

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

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?

Re: help with converting library to JS

>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

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

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

Re: help with converting library to JS

(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

Re: help with converting library to JS

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

Re: help with converting library to JS

> 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

help with converting library to JS

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:

Re: help with converting library to JS

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

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

Re: help with converting library to JS

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

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

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

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

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

Re: Why no AUDIO_F32 support in the SDL Audio wrapper

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