542635 - Distinguish "unable to play audio" and "no audio hardware".

Status: RESOLVED INACTIVE

(Core :: Audio/Video: Playback, defect)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

If we have a file which only has audio which we can decode but which we can't play (such as http://mxr.mozilla.org/mozilla-central/source/content/media/test/crashtests/495794-1.ogg ; the crashtest from bug 495794) we will pretend to play it, and advance the audio clock, despite no sound being produced.

The HTML5 resource load algorithm says:

"If the media data can be fetched but is found by inspection to be in an unsupported format, or can otherwise not be rendered at all [...] Abort this subalgorithm, returning to the resource selection algorithm."

We should instead try to load the next resource candidate, or throw an error if there are none. To do this, we must distinguish the case where the audio is in a format where we can't play, and the case where the audio is in a format we can play, but there's no sound hardware to play it. Currently we can't make this distinction. In the later case, we should still pretend to play (otherwise our tests won't work).

One suggested solution: change nsAudioStream so that we can initialize it during loading metadata (rather than on playback start), and change libsydneyaudio so that it can distinguish the failure modes, and propogate that error through to our decoder. We can then abort the load before onloadedmetada fires, or continue to load and playback using the system clock as appropriate. 

If we still have an video stream which we can playback, but we can't play the audio stream, we should still play the video stream using the system clock, we shouldn't raise an error in this case.

Likely these changes will cause content\media\test\crashtests\495794-1.html to timeout.

Comment 1

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.