Closed
Bug 846329
Opened 11 years ago
Closed 11 years ago
mozAudioContext decodeAudioData only uses the left channel
Categories
(Core :: Web Audio, defect)
Tracking
()
RESOLVED
FIXED
mozilla22
People
(Reporter: aykevanlaethem, Assigned: ehsan.akhgari)
References
Details
Attachments
(4 files)
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•11 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.
Assignee | ||
Comment 2•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
I'll push to the try server and adjust the fuzz tolerances in the test before landing.
Attachment #721018 -
Flags: review?(paul)
Assignee | ||
Comment 5•11 years ago
|
||
Desktop: https://tbpl.mozilla.org/?tree=Try&rev=64caf8dc2e7b Mobile: https://tbpl.mozilla.org/?tree=Try&rev=7acf443d5cd0
Assignee | ||
Comment 6•11 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•11 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.
Updated•11 years ago
|
Attachment #721018 -
Flags: review?(paul) → review+
Assignee | ||
Comment 8•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/c2877e674a4c
Reporter | ||
Comment 9•11 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)?
Comment 10•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c2877e674a4c
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Reporter | ||
Comment 11•11 years ago
|
||
Confirmed. The nightly builds sound much better now.
Assignee | ||
Comment 12•11 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•11 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.
Description
•