AudioContext() + createMediaElementSource() + createScriptProcessor() → audioprocess event test(Published November 28th, 2013. Updated 11/30.)
Related: createAnalyser() method test.
Objective: Retrieve audio channel data during playback using the Web Audio API, with a standard Audio() object as the media source. It is expected that the media source approach avoids complexity and performance considerations (sequential loading, memory, decoding) associated with the alternate XHR + "arraybuffer" response approach - particularly when using longer sounds. (Related article.)
Expected: Audio channel data should be available via the audioprocess event of an object returned from an audio context's createScriptProcessor method, when using createMediaElementSource() and specifying an Audio() object.
Observed (summary): Audio channel data is not shown under Safari 7 or iOS 7, despite successful object creation following "expected" method as described. Firefox chokes on initial playback, does not respect <audio> volume control and incorrectly reflects playback position (bugzilla #944924.) Chrome stops firing audioprocess when Chrome DevTools are opened(?)
Warning: Firefox and/or iOS might play incredibly loud digital noise, ignoring system volume settings, during seek or playback. Don't wear headphones directly on ears to be safe.
Refer to console for JS debug output, event attachment messages etc.
Chrome 30.0.1599.101 m (WinXP) and Chrome Canary (Canary 33.0.1722.0 on OS X 10.9) appear to stop firing audioprocess when the Chrome Dev Tools / console is opened for the first time in the window, and possibly on subsequent page loads. setTimeout() from within canplay seems to help, but not prevent the issue. Filed http://crbug.com/324493.
Related Chrome bug where wait for window.onload() is required for visualization to work: crbug.com/112368.
Firefox 25 on WinXP + Firefox Aurora 27.0a2 on OS X: Initial playback (via autoplay = true;) sometimes freezes with UI at 0:01. Clicking within UI to seek causes playback to resume. <audio> shows the playback head fixed at end of UI (sound duration) during playback. Clicking to seek within the <audio> element works for the audio, but the time/position UI either freezes at the seeked-to position or jumps to the end. Subsequent pause/play actions further confuse the position UI. (Bugzilla #944924.)
Cross-domain restrictions appear to apply to Firefox, but no CORS-related warnings were shown in the console. In testing, Chrome was able to play a cross-domain sound with channel data, sans-CORS headers.
Firefox Aurora does not play sound when loading this page (and the audio) from the local file system, via file:// - in Chrome, this works and sound plays as expected.
Firefox does not respect volume attribute of original <audio> element, whether initial value set via JS or by user clicking volume control in UI during playback. (Chrome respects both.)
Safari, iPhone 5S with iOS 7.0.4: audioprocess event does not fire after starting playback via touch.
Safari 7.0 (9537.71), OS X 10.9: audioprocess event does not fire after playback begins (webkit #125031.)