937061 - Web Audio buffer playback has changed to a 'metallic' tone.

Status: RESOLVED WORKSFORME

(Core :: Web Audio, defect, P2)

Description

[Jukka Jylänki]

1. Visit https://dl.dropboxusercontent.com/u/40949268/Bugs/long_beep.html
2. Press Start audio.

Repeat the above with FF25.0, and Nightly 2013-11-10.

Result: In FF25.0, audio playback sounds good (modulo the cracking noises reported in bugs #937054 and #937957) and the same as in Chrome and Opera. In the Nightly version, the audio clip sounds different, and the tone is "metallic" or "crisp", which does not sound right.

Comment 1

[Jukka Jylänki]

Aurora 25.0a2 2013-08-14 sounds good.
Aurora 27.0a2 2013-11-10 sounds bad.

Comment 2

[Jukka Jylänki]

Beta 26.0 sounds good.

Comment 3

[Maire Reavy [:mreavy]]

Karl -- Can you look at this?  It seems like something that got fixed in 27 (or fixed in 28 and uplifted to 27) caused this regression.  Thanks!  (Note this is different from bug 937054 and bug 937057.)

Comment 4

[(no longer active)]

I can't reproduce this on Mac, FWIW.

Comment 5

[Jukka Jylänki]

Tested this on another computer with Win8.1 and 5.1 audio speaker set with FF25.0, Nightly 27.0a1 2013-10-14 and Nightly 28.0a1 2013-11-11, and there the issue does not reproduce, each sounded good.

Comments 0-2 were tested on a Macbook Air running Windows 7 in bootcamp with the built-in laptop speakers. Interestingly, switching to a Plantronics headset (one of the Mozilla-provided mic+speaker headsets Jonathan Lin gave to me while I was in Toronto a few months ago) makes the audio playback sound identical in FF25.0 and latest Nightly on that Macbook Air as well. So, the speakers do seem to matter.

As an example, I recorded an audio file with microphone to demonstrate the difference that the MBAir speakers are giving, listen to https://dl.dropboxusercontent.com/u/40949268/Bugs/webaudio_tone_comparison.flac

The test clip plays two beeps. The first one is Firefox 25, which sounds good. The second one is latest Nightly, which sounds off. See legend here: https://dl.dropboxusercontent.com/u/40949268/Bugs/webaudio_tone_comparison.png

Comment 6

[Karl Tomlinson (:karlt)]

What sample rate do you see at http://people.mozilla.org/~karlt/sampleRate.html?
Does connecting/disconnecting the headphones affect the sample rate reported?

Can you switch speakers while the tone is playing please, to see whether the extra metallic tones are introduced/disappear on switch?

Ralph identified two extra peaks in the spectrum at about 3764 and 4111 Hz.

Comment 7

[Jukka Jylänki]

The sampleRate page reports "Web Audio sample rate = 44100 Hz" both with and without headphones connected.

Starting the playback without headphones on (getting bad output from speakers) and connecting headphones on the fly does not give bad output from headphones. Similarly, starting the playback with headphones on (good output) and disconnecting them on the fly does not give good output on the speakers, the speaker output is still bad.

Btw, another thing I noticed while playing with this that in Opera and Chrome, pressing the "Start audio" or "Stop audio" button on the test page will immediately start audio playback, but in Firefox, both Start audio and Stop audio have an about 1-1.5-second delay before the action carries out. Is that a bug or is it allowed by the spec?

Comment 8

[Karl Tomlinson (:karlt)]

Are you able to try these builds and check for the metallic sound, please?

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1382018895/
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1382019735/

One should report sample rate of 44100 and the other 48000.
Bug 907817 and bug 918861 landed in that range.

(In reply to Jukka Jylänki from comment #7)
> Starting the playback without headphones on (getting bad output from
> speakers) and connecting headphones on the fly does not give bad output from
> headphones. Similarly, starting the playback with headphones on (good
> output) and disconnecting them on the fly does not give good output on the
> speakers, the speaker output is still bad.

Thanks.  I assume Firefox is outputting the same sound to each system, but headphones interpret the output differently from the speakers.  It is perhaps possible that there is some very high frequency component that the speaker drivers are folding back into the audible range, but Firefox should not be producing this high frequency component.

I assume it is possible to capture the output of Firefox directly to a file, but I don't know how.

> Btw, another thing I noticed while playing with this that in Opera and
> Chrome, pressing the "Start audio" or "Stop audio" button on the test page
> will immediately start audio playback, but in Firefox, both Start audio and
> Stop audio have an about 1-1.5-second delay before the action carries out.
> Is that a bug or is it allowed by the spec?

Perhaps that is allowed, but that is a bug because it is not the intended behavior.  The delay should be less than half a second.  Can you open to new bug to track that, please?  Relevant info would be whether it happens with both headphone and speakers, whether Firefox 25 is different to Nightly, and whether the delay gets longer with time after page load.

Comment 9

[Jukka Jylänki]

The first link http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1382018895/ sounds good.

Unfortunately I was able to test the second link, running that one immediately crashes on loading https://dl.dropboxusercontent.com/u/40949268/Bugs/long_beep.html .

Comment 10

[Karl Tomlinson (:karlt)]

Thanks.  I guess the crash is bug 928615, and the next build with that fixed is
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1382417707/

Comment 11

[Jukka Jylänki]

Thanks. A run with http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1382417707/ sounds bad.

Comment 12

[Karl Tomlinson (:karlt)]

Full regression range is a few days long:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=616980966644&tochange=c442591daec0

Comment 13

[Karl Tomlinson (:karlt)]

(In reply to Jukka Jylänki from comment #7)
> Btw, another thing I noticed while playing with this that in Opera and
> Chrome, pressing the "Start audio" or "Stop audio" button on the test page
> will immediately start audio playback, but in Firefox, both Start audio and
> Stop audio have an about 1-1.5-second delay before the action carries out.
> Is that a bug or is it allowed by the spec?

That sounds like bug 919215.

Comment 14

[Preeti Raghunath(:Preeti)]

Please help with user impact here.

Comment 15

[Jason Smith [:jsmith]]

(In reply to Preeti Raghunath(:Preeti) from comment #14)
> Please help with user impact here.

Specifically with the partner app in question here.

Comment 16

[Jukka Jylänki]

With help from Louis Stowasser, we tested the impact to the partner app today, and could not hear a difference: Web Audio sounded the same as using an audio tag. However, the issue reported in this bug still exists, but gladly not critical to the partner app.

Comment 17

[Jason Smith [:jsmith]]

Ok - in that case, I'm not going to block on this if there's no clear impact to the partner app here.

Comment 18

[Paul Adenot (:padenot)]

I checked for everything mentioned in this page, and everything sounds good. Also, there is a missing 2 factor in the formula for the sine, which is the reason why the sine is at 220 and not at 440, and sounds an octave lower than the video.