1083622 - Mozilla web-audio processing fails on streams

Status: RESOLVED DUPLICATE of bug 996685

(Core :: Web Audio, defect)

Description

[Anton Triola]

Attachment: compressor-test.html

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140923175406

Steps to reproduce:

Copy this Mozilla example code to a directory on your drive:
https://raw.githubusercontent.com/mdn/compressor-example/gh-pages/index.html
(modified file compressor-test.html included in attachment)

Replace line 19 - <source src="viper.ogg" type="audio/ogg">
with:
<source src="http://74.202.111.236:2512/;" type="audio/mp3">

Comment-out line 20 - <source src="viper.mp3" type="audio/mp3">
Comment-out line 31 - var pre = document.querySelector('pre');
Comment-out line 35 - pre.innerHTML = myScript.innerHTML;

Open as file:/// in Firefox 32.0.3, click play-arrow. 
Open as file:/// in Chrome 38.0.2125.104 m, click play-arrow.



Actual results:

In Firefox, the code connects to the internet and downloads the stream, but no sound results.

In Chrome, the code connects to the internet and downloads the stream, the sound plays normally and the example compressor is effective.

Commenting-out the entire <script>...</script> javascript will allow Firefox to play the stream as expected, but without web-audio processing.


Expected results:

The example Mozilla compressor code should have played the indicated stream, with or without the compressor engaged and without having to comment-out the web-audio javascript.

See my post below for further comments and my testing regimen:
http://stackoverflow.com/questions/26389983/mozilla-web-audio-processing-fails-on-streams

Comment 1

[Karl Tomlinson (:karlt)]

See also bug 937718.

Comment 2

[Anton Triola]

So does this mean that bug 996685 and bug 1083622 fall victim to Same Origin Policy?

Does it also mean that this is by design and will remain as it is now in the Mozilla code base?

That would be unfortunate on several levels if it is the case, streaming audio is one area that could benefit greatly from the DSP afforded by web-audio functionality, painting it with the same brush as cross-origin web pages in an iframe or other XHR might deserve a serious rethink.

Comment 3

[Karl Tomlinson (:karlt)]

The intended behavior is "a MediaElementAudioSourceNode MUST output silence instead of the normal output of the HTMLMediaElement if it has been created using an HTMLMediaElement for which the execution of the fetch algorithm labeled the resource as CORS-cross-origin." [1]

So the behavior for the test case here is as expected.

There is an unintended bug in the behavior with crossOrigin = "anonymous" producing silence even with Access-Control-Allow-Origin: *.  That is tracked in bug 937718, which would welcome a fix.

[1] http://webaudio.github.io/web-audio-api/#security-with-mediaelementaudiosourcenode-and-cross-origin-resources

Comment 4

[Anton Triola]

Thank you for pointing out the specification, Karl.

Unfortunately, even if the access-control bug were to be corrected, I've yet to find any access-control headers while examining streams usually associated with sites such as Shoutcast and others of the ilk, so DSP on commonly accessed streaming-audio is effectively dead, at least in Firefox.

But I do appreciate your patience in explaining Mozilla's adherence to the W3C spec.