846329 - mozAudioContext decodeAudioData only uses the left channel

Status: RESOLVED FIXED

(Core :: Web Audio, defect)

Description

[aykevanlaethem]

Attachment: Waveforms of Chrome and Firefox.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20130227 Firefox/22.0
Build ID: 20130227030925

Steps to reproduce:

I decoded and played music with the new mozAudioContext in Firefox Nightly 22.0a1 (2013-02-27)

(This because Firefox Nightly is the only browser supporting AudioContext on Android.)


Actual results:

The audio didn't sound good. I compared with Chrome and there was a large difference in audio quality. After a bit testing, it turned out Firefox uses only one channel (the first channel). I hacked something together to test this behavior:
http://jsfiddle.net/KFSCN/1/
It displays a (very ugly) waveform of the center of a loaded song. In Chrome, there is a visible difference. In Firefox, there isn't such a difference. Comparing the two, it turns out Firefox only uses the first channel (channel 0).

This problem isn't there when playing the sound with the <audio> HTML element.

Besides, it seems, when comparing Chrome and Firefox, that one of them moves the audio data a bit, just as if Chrome adds some silence to the start or Firefox removes something from the start. (It's lossless WAV, so there should be no difference). But this is a separate possible bug.


Expected results:

It should just play stereo. Both channels. And not only play one channel.

Comment 1

[aykevanlaethem]

Oops - forgot to mention I have tested this on Android too and it has the same bug. So it's probably not operating-system dependent.

Comment 2

[(no longer active)]

Attachment: Test ogg file

You're right.  This is clearly visible with this test file, which has an entirely different waveform for both of its channels.

Comment 3

[(no longer active)]

Attachment: 48KHz test case

This is the same file sampled at 48000Hz, and with this the bug doesn't happen.  So, this should be a bug in the resampling code that we use when the sampling rate of the input buffer doesn't match the sample rate of the audio context.

Comment 4

[(no longer active)]

Attachment: Patch (v1)

I'll push to the try server and adjust the fuzz tolerances in the test before landing.

Comment 5

[(no longer active)]

Desktop: https://tbpl.mozilla.org/?tree=Try&rev=64caf8dc2e7b
Mobile: https://tbpl.mozilla.org/?tree=Try&rev=7acf443d5cd0

Comment 6

[(no longer active)]

aykevanlaethem, thank you *so* much for this bug report, this is a great example of a very helpful and detailed bug report.  Please keep up the good work!  :-)

Comment 7

[(no longer active)]

I realized I posted this desctiption on the reason behind the bug on the wrong bug!

speex_resampler_process_*'s input buffer is not affected by its channel_index argument, hence the bug.  I'll need to adjust the tests for the fix.

Comment 8

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c2877e674a4c

Comment 9

[aykevanlaethem]

Thank you for fixing this ;-)

I have tested this with the latest nightly, but the fix wasn't there (yet). When will it land? In the next nightly (seeing the last comment)?

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c2877e674a4c

Comment 11

[aykevanlaethem]

Confirmed. The nightly builds sound much better now.

Comment 12

[(no longer active)]

(In reply to comment #11)
> Confirmed. The nightly builds sound much better now.

Cool, thanks a lot for verifying this fix.  :-)

Comment 13

[(no longer active)]

Mass moving Web Audio bugs to the Web Audio component.  Filter on duckityduck.