STR: 1. Launch the UI Test app 2. Click on audio tag test 3. Click play button to playback specific media Such as: AC_prgrssv__Retro_Alarm_Clock_v02_SOFT.ogg, AC_progressive_dapple10.ogg AC_progressive_shimmer07.ogg expected: It will have sound. actual: It won't have sound without any error log.

Reopening. This is not a dup; it took me 1 week to figure out this :-/ Those OGG files are supplied by Patryk; if we cannot have those files play correctly, Patryk cannot replace the current temporary alarm sounds and fix bug 799190.

I can provide the sounds in both OGG or MP3. Philosophically we'd want to use OGG, but if its an issue getting it working, I can just supply you with MP3s.

This could also affect arbitrary .ogg music files so let's block on getting this at least investigated. roc, do you know who could take this?

Those files (from https://github.com/ian-liu/gaia/commit/e9e337325d6425f8b85d8078fe69ee3a3819ca09) play OK for me on desktop. That should be mostly the same code as we're using in B2G, but we are using Tremor on mobile. Could it be a Tremor bug? Do the files play in the Android browser? How about the B2G browser? Assigning to Ralph.

Indeed, these don't play in Android Firefox: http://people.mozilla.org/~roc/AC_progressive_shimmer07.ogg http://people.mozilla.org/~roc/AC_progressive_dapple10.ogg http://people.mozilla.org/~roc/AC_prgrssv__Retro_Alarm_Clock_v02_SOFT.ogg So it could be Tremor. I don't know who owns Tremor bugs...

Is ogg maybe routed to the vendor library, and the latter breaks?

It doesn't look like that could be happening, but maybe I'm wrong.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6) > So it could be Tremor. I don't know who owns Tremor bugs... FWIW, these play fine in Tremor when built stand-alone (on x86).

(In reply to Patryk Adamczyk [:patryk] UX from comment #3) > I can provide the sounds in both OGG or MP3. Philosophically we'd want to > use OGG, but if its an issue getting it working, I can just supply you with > MP3s. Can you supply .opus versions? That might serve as a work-around. You'll need opusenc from the opus-tools package. http://opus-codec.org/downloads/

The files from comment #6 are all 96 kHz, which might be the problem.

According to PR_LOG on Android, it's using the builtin decoder, and nsBuiltinDecoderStateMachine::PlayFromAudioQueue is writing to the audio queue. However, I don't hear any audio and the controls flicker and disappear.

I've confirmed the sample rate issue. The following files play on Android: http://people.mozilla.org/~rgiles/2012/firefoxos-48kHz.ogg http://people.mozilla.org/~rgiles/2012/firefoxos-44kHz.ogg This one does not: http://people.mozilla.org/~rgiles/2012/firefoxos-96kHz.ogg All three are encoded from the same 96 kHz WAV file after resampling with sox, and all three play on desktop. It may be that 96 kHz just doesn't currently work on Android. Cubeb's OpenSL backend rejects sample rates over 48kHz. http://hg.mozilla.org/mozilla-central/file/324985f4c4ea/media/libcubeb/src/cubeb_opensl.c#l186

Android is currently using the sydney audio back end, and indeed it fails to initialize the stream: 10-29 14:35:19.394 E/AudioTrack-Java( 4392): [ android.media.AudioTrack ] getMinBufferSize(): 96000Hz is not a supported sample rate. Closing as a duplicate of the resampler feature bug. The work-around is to resample to 48 kHz before encoding resources for Firefox OS.