W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2017

Re: Float denormals handing in audioworklet ?

From: Raymond Toy <rtoy@google.com>
Date: Thu, 13 Jul 2017 09:02:17 -0700
Message-ID: <CAE3TgXEuK=HcB8sTKgZMfLtUsb399Btq--zwk0D7N23Gt5Q_=g@mail.gmail.com>
To: Stéphane Letz <letz@grame.fr>
Cc: Audio Working Group <public-audio@w3.org>
That's a very good question.  Chrome's WebAudio implementation has FTZ
turned on when running the audio graph. I think this is fine for the
built-in nodes, but it might be problematic for an AudioWorklet.  If FTZ is
turned on for a worklet, you end up in a funny situation where plain old
javascript code behaves differently when run on the main thread or run in
an AudioWorklet.

It would certainly break my expectations for Javascript code.

My understanding that only x86 processors have slow denormals. (ARM and
MIPS are very fast and don't have a denormal penalty).  The denormal
penalty is also much less on newer x86 chips, but it is not completely
gone.  I've complained to Intel about this.  Apparently if you have a
fused-multiply-add instruction (which new x86 chips have), fast denormal
processing is basically free.


On Thu, Jul 13, 2017 at 4:04 AM, Stéphane Letz <letz@grame.fr> wrote:

> Hi,
>
> We have developed a WebAssembly backend in the Faust (
> http://faust.grame.fr) audio DSP language (http://faust.grame.fr/news/
> 2017/01/13/faust-webassembly.html). Then we connect the generated « DSP
> as a WebAssembly module » in a Web Audio ScripProcessor node.
>
> Testing this code with various DSP and in particular physical models, we
> see a lot of float denormals. We « solve » the problem by doing an
> automatic software Flush To Zero in the generated code. This solution helps
> but is not satisfactory, since we would prefer to have hardware FTZ
> activated in the first place, as we can do in C/C++ code (on Intel for
> instance using this kind of flags #define AVOIDDENORMALS
> _mm_setcsr(_mm_getcsr() | 0x8040))
>
> When we raised this float denormals issue years ago with our Faust asm.js
> backend, the answer basically was that JavaScript would not support FTZ
> control in the near future
>
> What will be the situation with audioworklet ? Since we understand the
> audio code will be computed in a special real-time worker thread, then this
> thread could be set with hardware FTZ ? Is it specified somewhere?
>
> Regards
>
> Stéphane Letz
>
Received on Thursday, 13 July 2017 16:02:45 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 July 2017 16:02:45 UTC