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.
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.
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
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.
I'll push to the try server and adjust the fuzz tolerances in the test before landing.
Attachment #721018 - Flags: review?(paul)
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! :-)
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.
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)?
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Confirmed. The nightly builds sound much better now.
(In reply to comment #11) > Confirmed. The nightly builds sound much better now. Cool, thanks a lot for verifying this fix. :-)
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.