mozAudioContext decodeAudioData only uses the left channel

RESOLVED FIXED in mozilla22

Status

()

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: aykevanlaethem, Assigned: Ehsan)

Tracking

22 Branch
mozilla22
x86_64
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

Reporter

Description

6 years ago
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.
Reporter

Comment 1

6 years ago
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.

Updated

6 years ago
Blocks: webaudio
Assignee

Comment 2

6 years ago
Posted video 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.
Assignee: nobody → ehsan
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee

Comment 3

6 years ago
Posted video 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.
Assignee

Comment 4

6 years ago
Posted patch Patch (v1)Splinter Review
I'll push to the try server and adjust the fuzz tolerances in the test before landing.
Attachment #721018 - Flags: review?(paul)
Assignee

Comment 6

6 years ago
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!  :-)
Assignee

Comment 7

6 years ago
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.
Attachment #721018 - Flags: review?(paul) → review+
Reporter

Comment 9

6 years ago
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)?
https://hg.mozilla.org/mozilla-central/rev/c2877e674a4c
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Reporter

Comment 11

6 years ago
Confirmed. The nightly builds sound much better now.
Assignee

Comment 12

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

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

Comment 13

6 years ago
Mass moving Web Audio bugs to the Web Audio component.  Filter on duckityduck.
Component: Video/Audio → Web Audio
You need to log in before you can comment on or make changes to this bug.