Re: Denormalized float numbers in asm.js and the WebAudio API

Le 19 juin 2014 à 15:11, Paul Adenot <> a écrit :

> On 19/06/2014 14:39, Stéphane Letz wrote:
>> Hi,
>> We successfully compile our C++ audio processing code with emcripten in asm.js to deploy on the web using the WebAudio API , so running the resulting asm.js code in a ScriptProcessorNode in the Web Audio API. 
>> Our C++ code uses the following denormalized float number protection code ("protection" is needed since denormalized float number computation is awfully slow and has to be avoided): 
>> #ifdef __SSE__
>>    #include <xmmintrin.h>
>>    #ifdef __SSE2__
>>        #define AVOIDDENORMALS _mm_setcsr(_mm_getcsr() | 0x8040)
>>    #else
>>        #define AVOIDDENORMALS _mm_setcsr(_mm_getcsr() | 0x8000)
>>    #endif
>> #else
>>    #define AVOIDDENORMALS
>> #endif
>> Basically we add a call at AVOIDDENORMALS before each audio  block processing. It seems this AVOIDDENORMALS is just removed by the emcripten compiler and so we get asm.js code that seems to produce denormalized floats and the speed issue occurs.
>> If we run the same kind of code in a pure native CoreAudio application on OSX, adding AVOIDDENORMALS is not needed once it seems the CoreAudio real-time thread is automatically protected for denormalization. Our understanding of the WebAudio API implementation is that ScriptProcessorNode code does not run in the audio real-time thread, so the code in not protected for denormalization.
>> It is a know problem? Any solution others could have experimented?
> The script processor node _callbacks_ don't run in the audio thread. The
> buffer eventually gets sent to the audio thread for latter processing.
> However, this does not seem to be an issue with the specification, but
> an issue with the implementation of the specification.
> I know Gecko, Webkit and Blink for example flush denormals to zero in
> some cases in the Web Audio API, and you should go file a bug in their
> bug tracker so that they can look into it.
> Firefox:
> Chrome:
> Webkit:
> Speaking for the Firefox side, I'll be happy to help you there.
> Cheers,
> Paul.

Thanks. I've tested and the problem occurs on OSX on :

Version 35.0.1916.153

FireFox 30.0 and nightly 33   ==>  submitted for bug 1027624

Safari/WekKit nightly built


Received on Thursday, 19 June 2014 13:57:27 UTC