Dale, can you take a look? I can repro it on Windows. at 0.00004 I can still hear, but on 0.00005, no sound at all. 

Anything that mentions audio context is WebAudio.

I can confirm that win and linux produce no audible output with a gain of 0.00003. Mac works fine. I used the same headphones for this test.

For the record, Chrome has always converted the floating-point audio samples to 16-bit samples, except on Mac. Hence, silence is the expected output for the repro case when the gain is set to 0.00003, (which is about 0.98 bits for a 16-bit value).

Raymond, this is quite discouraging to hear that Chrome would be worse than other browsers for audio on Windows.

Besides, even before we reach the point where no sound is heard, the signal is distorted in a way that would prevent from building a descent audio application in the browser.

Please tell us there is a chance to see it changed and resolved...

Thanks

hameshiv@ Is this related to this particular bug (low gain not audible)?  If not, please file a new bug with a repro case that illustrates the distortion that you hear.  We can't fix it if we don't know how to reproduce it.

Raymond, the fact that Chrome usees 16-bit samples has a very big impact on us, as it limits the dynamic scope of the audio. Our app requires a dynamic scope of over 100 dB, and with the current Chrome implementation it seems impossible.

Raymond,

Some important additions to the ongoing discussion:

- We do need a correct dynamic range because we deal with audiology tests. Attenuation would be a good solution for low gain signals, but definitely spoil the other end of the required range.

- Please look at the attachement: it shows a terrible degradation of the signal, starting around a gain of 0.0001 which means a usable dynamic of only 80 dB, if we only wish to have a descent sinusoidal signal.

- I can't help but thinking of the people who are buying 24 bit sound cards only to discover that this hardware is of no use when listening to music online with Chrome...

I'm quite sure that there are other considerations behind this decision of handling only !6 bit audio in Chromium, but it's our role to suggest a vital evolution of this behavior.

Thanks for paying attention !

Deleted: IMG_01112016_191250.png 86.3 KB

	IMG_01112016_191250.png 86.3 KB View Download

How did you capture the data for the graphs?  Why is there no DAC output filtering being done?

I suspect most people listening to online music won't notice the difference between a 16-bit or 24-bit card. I'm pretty sure I can't, but my ears are pretty terrible.

Chrome isn't actively trying to degrade quality. I suspect it was 16 because that's what was most commonly available way back when when the code was written.

We are looking into this.

About the method: it's a zooming over the wave recorded using a loopback configuration on any recording software (Goldwave here). As far as I understand, it's a pure digital visualization of the output signal coming directly from the browser.
Anyway, it must be said that we clearly hear the degradation, more than 10 dB before the sound gets cut. So the graph is only a clue for something we already know and observe without any tool.

About the business value: I agree that most people won't be sensitive to the finest sound. But the fact is that hardware is sold and looked for by some people there, and they do expect from a up-to-date browser to stick with their use. 
Besides, we aim to bring an era of professional use of the browser for precise applications, in music editing or in our case, healthcare, and we clearly see Chromium as the right infrastructure to achieve that.

So you see, there are good reasons for this humble request.

Thanks for being so quick at responding.

Ah, that explains the quantization artifacts because you're not looking at the actual analog output.

I didn't mean to imply that high quality audio is not an important goal.  For WebAudio, it is one of the most important goals so we do want to provide the best output quality from the browser.

Oh, and I didn't explain my comment about an attenuator.  I meant the attenuator would only be used for the very low amplitude range.  For the higher end, you'd turn it off.  This is, I think, pretty manual, so not the best solution for you, I guess.

Analog output: I'm not looking at it, yet this is what I hear, and it doesn't sound good. At all.

Attenuation: we know that it's a solution but 1) we're building a SaaS product, so hardware is something we tend to avoid, totally 2) we can't expect from our users that they would switch an attenuator on and off in current use

:-)

Raymond, it's definitely great to hear that output quality is an important goal for WebAudio.

Thanks for all this discussion and the efforts you deliver between messages...

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9017c72f75614b18f1af80e90c77d172413644bc

commit 9017c72f75614b18f1af80e90c77d172413644bc
Author: rtoy <rtoy@chromium.org>
Date: Wed Nov 02 16:36:44 2016

Support floating-point audio output for Linux

Instead of converting the audio to 16-bit PCM, pass the audio data
directly to Pulse Audio as floating-point numbers and let Pulse Audio
do whatever is necessary.

Using the test url, a gain of 0.00002 produces output on my Z620 where
it didn't before.  There is silence for a gain of 0.00001, but that
could be due to many things including pulse audio, the actual audio
driver, the audio HW, and my headphones.

BUG= 659641 
TEST=Run test url from bug and set gain to 0.00002 and hear output

Review-Url: https://codereview.chromium.org/2469023002
Cr-Commit-Position: refs/heads/master@{#429301}

[modify] https://crrev.com/9017c72f75614b18f1af80e90c77d172413644bc/media/audio/pulse/pulse_output.cc
[modify] https://crrev.com/9017c72f75614b18f1af80e90c77d172413644bc/media/audio/pulse/pulse_util.cc

For the record, I installed jack (passing pulse audio through jack) and used audacity to capture the audio.  With the gain set to 0.00001 I can't hear anything, but audacity clearly shows a pretty nice sine wave output.  Well, audacity doesn't seem to want to zoom in enough to see the waveform, but the spectrum shows a clear narrow peak at 1kHz with amplitude around -83 dB

It's great to see how you work, guys!

Would the fix for Windows be any different ?

Thanks for being so responsive.

It would be great if you could grab a linux nightly build and try it out on your app.

Windows is being worked on; I hope to have it landed in the next day or two.

Where do we find a nightly build?

https://www.chromium.org/getting-involved/dev-channel has information on getting the linux canaries.

Hello Raymond,

Here are the results of our tests, from left to right:

- Chrome stable at 0.00005 gain
- Chromium nightly build at 0.00005 gain
- Descending on nightly from 0.00005 to 0.00001 (four steps) and back to the signal threshold of 0.000016

As you can see:

- Chromium is better than Stable, but still not usable (triangle shaped wave)
- The sound volume remains the same under 0.00005 and is silent below 0.000016.

All tests performed on Ubuntu 16.

Hope it will help... Thanks !

Deleted: analysis11-3.jpg 270 KB

	analysis11-3.jpg 270 KB View Download

Thanks for the data. I'll have to hook up some better analysis tools on my end to see what's going on.  The middle diagram with a gain of 0.00005 kind of looks like its been mostly quantized to 17 bits, which is strange.

Please also verify the number of bits of output for your audio device. My Z620 apparently has a a RealTek audio device supporting 24-bit output.

We use an AudioQuest Dragonfly which is set to 24 bits. I'll cross-check again.

Meanwhile, everything looks great on Mac - see attachment.

Deleted: desc-mac.jpg 133 KB

	desc-mac.jpg 133 KB View Download

I apologize: you're totally right and our sound card wasn't on 24 bits.
Now we have a perfect output from 0.00005 to 0.00001 !

In attachment you'll see a comparison between linux and mac.

So, well, YEAH ! we have a fix. Great job !
Looking forward to see it deployed further.

Thanks for all...

Deleted: fixed.jpg 286 KB

	fixed.jpg 286 KB View Download

Yay!  Thanks so much for testing!  I was about ready to see if I could find an oscilloscope somewhere to look at the actual audio output from the headphone jack.  Then we'd know for sure.

Windows fix should be coming out later today, so if that matters to you, I'd really appreciate if you could grab a windows Canary build tomorrow and test it.

Oh, and for the record, I don't think my use of audacity and jack were really correct. I think pulse audio is taking float samples and passing them to jack as floats and audacity is grabbing the floats from jack.  Jack then passes the floats to ALSA which does whatever it wants to send to the hardware.

I surely will. I'll let you know.

Audacity hasn't good zooming abilities at those levels. I just exported 32-bit PCM files to Goldwave on Windows.

Anyway, with audiology headset, one can easily hear the difference. No comparison.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/70fe19f8a20761c939444f2d3b8c6d1daf13c975

commit 70fe19f8a20761c939444f2d3b8c6d1daf13c975
Author: rtoy <rtoy@chromium.org>
Date: Fri Nov 04 17:20:07 2016

Support floating-point audio output for Windows7+

Instead of converting audio to 16-bit PCM, pass the audio data
as floating-point directly on the low-latency path (WASAPI)

BUG= 659641 
TEST=Run test url from bug and set gain to 0.00002 and hear output

Review-Url: https://codereview.chromium.org/2475453003
Cr-Commit-Position: refs/heads/master@{#429928}

[modify] https://crrev.com/70fe19f8a20761c939444f2d3b8c6d1daf13c975/media/audio/win/audio_low_latency_output_win.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ae586bc923a3b81870809fc9a77b78c4d58bcc0a

commit ae586bc923a3b81870809fc9a77b78c4d58bcc0a
Author: jmadill <jmadill@chromium.org>
Date: Fri Nov 04 20:36:54 2016

Revert of Support floating-point audio output for Windows7+ (patchset #4 id:60001 of https://codereview.chromium.org/2475453003/ )

Reason for revert:
Seems to have broken Windows GPU bots. Examples:

https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20x64%20Release%20%28NVIDIA%29/builds/7761
https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28AMD%29/builds/43
https://build.chromium.org/p/chromium.gpu.fyi/builders/Win8%20Release%20%28NVIDIA%29/builds/25111

Original issue's description:
> Support floating-point audio output for Windows7+
>
> Instead of converting audio to 16-bit PCM, pass the audio data
> as floating-point directly on the low-latency path (WASAPI)
>
> BUG= 659641 
> TEST=Run test url from bug and set gain to 0.00002 and hear output
>
> Committed: https://crrev.com/70fe19f8a20761c939444f2d3b8c6d1daf13c975
> Cr-Commit-Position: refs/heads/master@{#429928}

TBR=dalecurtis@chromium.org,tommi@chromium.org,rtoy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 659641 

Review-Url: https://codereview.chromium.org/2478893002
Cr-Commit-Position: refs/heads/master@{#430003}

[modify] https://crrev.com/ae586bc923a3b81870809fc9a77b78c4d58bcc0a/media/audio/win/audio_low_latency_output_win.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb52b0f9af558002450baf25cacbc98feb9201e2

commit fb52b0f9af558002450baf25cacbc98feb9201e2
Author: kbr <kbr@chromium.org>
Date: Sat Nov 05 00:20:32 2016

Run optional GPU trybots against changes to media/audio/ .

The main effect this has is to run the WebGL 2.0 conformance suite
against CLs in this directory, and subdirectories. This test suite
contains videos that test code paths in media/audio/, so running it on
CQ jobs should prevent breakage of these tests.

BUG= 659641 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2476053002
Cr-Commit-Position: refs/heads/master@{#430079}

[add] https://crrev.com/fb52b0f9af558002450baf25cacbc98feb9201e2/media/audio/PRESUBMIT.py
[add] https://crrev.com/fb52b0f9af558002450baf25cacbc98feb9201e2/media/gpu/PRESUBMIT.py

Hello,

Is there any news about the change in Windows ?

Thanks

The revised Windows CL is up for review.  It should be coming soon.  This will only work on Windows 7 and later, mostly. 

Hi Raymond,

Sorry to be insistent, but we'll be really glad to have some visibility on the Windows implementation.

Hope all is going well.

Thanks

Then you will be interested in https://codereview.chromium.org/2475953003/, which just got the necessary lgtm late Friday and is in the commit queue now. I hope it sticks this time.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1ffd6214d17f7228f307e67b32152866b67d6029

commit 1ffd6214d17f7228f307e67b32152866b67d6029
Author: rtoy <rtoy@chromium.org>
Date: Mon Nov 14 19:05:11 2016

Support floating-point audio output for Windows7+

Instead of converting audio to 16-bit PCM, pass the audio data
as floating-point directly on the low-latency path (WASAPI)

BUG= 659641 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
TEST=Run test url from bug and set gain to 0.00002 and hear output

Review-Url: https://codereview.chromium.org/2475953003
Cr-Commit-Position: refs/heads/master@{#431882}

[modify] https://crrev.com/1ffd6214d17f7228f307e67b32152866b67d6029/media/audio/win/audio_low_latency_output_win.cc

Hi there,

Tested and validated on Canary for Windows today.

Perfect sinusoidal signals and totally consistent gain detected on our analyzer.

Small step for Chromium, giant step for audio users !

Thank you all.

Thanks so much for testing!

I think we can consider this matter closed, at least on desktop.

Hi,

Sorry for the novice question, but how can we follow the deployment of this fix over the Chrome releases ?

Thanks

The change made it into Chrome 56 so, according to https://www.chromium.org/developers/calendar, 56 will become the stable version on Jan 31, 2017, approximately.  The omahaproxy viewer on that page will let you watch the progression of M56 from dev to beta to stable.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4f5539045e3c3eea9197ff328302d8dac89a6711

commit 4f5539045e3c3eea9197ff328302d8dac89a6711
Author: dalecurtis <dalecurtis@chromium.org>
Date: Tue Apr 11 23:08:25 2017

Enable float audio output on L+ Android devices.

We still need an interleaving step since there doesn't seem to be
planar output, but this avoids the float => s16 conversion.

Benchmarks show it's power neutral, but since it will have objective
improvements in some cases (see bug), lets land it.

BUG= 659641 
TEST=L+ device with Lollipop sounds correct.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2793123003
Cr-Commit-Position: refs/heads/master@{#463822}

[modify] https://crrev.com/4f5539045e3c3eea9197ff328302d8dac89a6711/media/audio/android/opensles_output.cc
[modify] https://crrev.com/4f5539045e3c3eea9197ff328302d8dac89a6711/media/audio/android/opensles_output.h