Closed Bug 879651 Opened 8 years ago Closed 8 years ago
no audio playback on Android x86
797.32 KB, application/octet-stream
807.01 KB, application/x-sharedlib
419.79 KB, text/plain
2.02 KB, text/plain
1.29 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release) Build ID: 20130512194445 Steps to reproduce: On both intel and amd devices, running android-x86.org (that I built myself from androix-x86) of ICS 4.0.4 Tried to playback video both webm and mp4, using both a plain <video> element and via an iframe embed from youtube. I also tried forcing use of stagefright by setting stagefright.force-enabled in about:config, as this is required to playback mp4 files on these devices. Actual results: Audio playback does not work. Audio playback does work using other native Android applications, eg. system sound effects. No errors are reported in logcat, though I do see the following in logcat when a video starts to play that seems to indicate the audio playback is being attempted at least: 06-05 04:40:06.280: D/AudioHardware(1529): AudioHardware pcm playback is exiting standby. 06-05 04:40:06.280: D/AudioHardware(1529): openPcmOut_l() mPcmOpenCnt: 0 and then this when video stops playback: 06-05 04:40:09.540: D/AudioHardware(1529): AudioHardware pcm playback is going to standby. 06-05 04:40:09.540: D/AudioHardware(1529): closePcmOut_l() mPcmOpenCnt: 1 Also I tested this with both the current Aurora build and a build done by myself locally after a Hg pull done earlier today. Expected results: Audio playback.
Component: General → Video/Audio
Product: Firefox for Android → Core
I can reproduce this problem on a Motorla RAZR i using the nightly x86 build. My STR: 1. Go to vimeo.com 2. Tap a video 3. Firefox goes into fullscreen and plays video I get no audio for the video. Testing on a Nexus 4 using ARM builds, I hear the audio for the same video. GCP/Chris - Any idea who the right people are to look into this?
Component: Video/Audio → General
Product: Core → Firefox for Android
Status: UNCONFIRMED → NEW
Ever confirmed: true
How are the tinderbox mozilla-beta-x86 builds? (No official candidate built yet) http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-beta-android-x86
I tried this tinderbox build: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-beta-android-x86/1370402353/fennec-22.0.en-US.android-i386.apk And it also has no audio playback, so I don't think this is a regression, I suspect that audio playback has never worked on x86 android builds. I'm more than happy to help work on this further as I'm building a custom version of firefox already anyway (for use in an embedded android device) so I have a build env all setup. Just need someone to point me to a starting point in the code?
Chris - Is there somewhere in the code where @maks can start looking? Also, is Chris Pearce a better contact for the audio stuff?
Matthew Gregan is probably the best person to ask about audio support in Firefox for Android.
(In reply to Chris Double (:doublec) from comment #5) > Matthew Gregan is probably the best person to ask about audio support in > Firefox for Android. Thanks. CC'ing Matthew
this is a regression. Vimeo was giving me some lip about videos not being licensed for mobile use, so I've been using http://camendesign.com/code/video_for_everybody/test.html to test this works: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2012/12/2012-12-20-12-15-07-mozilla-central-android-x86/ this doesn't: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013-06-06-03-11-28-mozilla-central-android-x86/fennec-24.0a1.multi.android-i386.apk
bisected with nightlies: last good: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013/03/2013-03-15-03-09-43-mozilla-central-android-x86/fennec-22.0a1.multi.android-i386.apk first bad: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013/03/2013-03-16-16-05-54-mozilla-central-android-x86/fennec-22.0a1.multi.android-i386.apk so, changeset-wise: last good: http://hg.mozilla.org/mozilla-central/rev/0f7261e288f2 first bad: http://hg.mozilla.org/mozilla-central/rev/0b052daa913c
There are 219 changesets in this range (http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0f7261e288f2&tochange=0b052daa913c) and several of them have to do with landing and enableing web audio as well the new cubeb backend. CC'ing ehsan and paul.
So, the new cubeb (our multiplatform audio library) backend I landed in that range (cubeb_audiotrack.c) is supposed to be used only on android 2.2. The way it works is that we try to use the OpenSL backend first, and if it does not work, we fallback on the backend landed on this range, that is supported on more Android versions. I would not expect this phone to be running 2.2, though, so we should be able to use OpenSL, which is a public API, supposed to be stable (the cubeb_audiotrack.c backend landed during this range dlopens a private Android library, and sometimes OEM change the libmedia.so library we open so the symbols we search for are not correct). Also, in case code fallbacks on the cubeb_audiotrack.c backend (I've seen this on occasion, because OpenSL sometimes has a maximum number of open streams), something that could help me put together a patch would be to get me the /system/lib/libmedia.so system library from this device. If we could get a logs from a debug build output, it could also be of great help. If someone is willing to do a bit of debug, getting the return value from |cubeb_init| and |cubeb_stream_init| in AudioStream.cpp would be a good start. If |cubeb_init| succeeds, having the string returned by |cubeb_get_backend_id| could also be of use so we can narrow down the issue. I would not expect the fact that WebAudio was preffed on by default during this range to be the cause of this problem.
Supposedly this bug is reproducible in the x86 Android emulator, which should help.
Hi I' the original reporter of this bug. Thanks again for looking into this so quickly, I really appreciate it! I saw this on my own build of the android-x86 project (http://www.android-x86.org/) running on various "desktop" x86 and amd hardware (and eeepc901 laptop). The android-x86 project is fairly "vanilla" AOSP, though ahvign dsiad that, they do make a number of changes to support runnign on c86 hardware, like their own Gralloc mesa implementation that works with i915 and radeon gpus. I can confirm that: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013/03/2013-03-15-03-09-43-mozilla-central-android-x86/fennec-22.0a1.multi.android-i386.apk *works* for me, so you are right, it is a regression, I just didnt test far enough back - my apologies for that. I'll attach /system/lib/libmedia.so from my build in case that can help. I'll also add debugs for the return values you asked for and attach the output from them as soon as I get a clean build done (a post clobber build takes well over an hour on my i7 laptop)
The relevant lines from the above logcat: 06-07 04:18:56.266 15622 15700 I Gecko - Cubeb: cubeb_init reslut: 0 06-07 04:18:56.266 15622 15700 I Gecko - Cubeb: cubeb_stream_init_result: -2 (sorry for spelling typo).
jsut in case here is the diff of the logcat output some you can see where that logcat output came from for AudioStream.cpp
bisect confirms that the new cubeb audio backend is what regressed this.
The next steps are to work out why the OpenSL backend is not working. Tracing opensl_init (http://hg.mozilla.org/mozilla-central/file/tip/media/libcubeb/src/cubeb_opensl.c#l124) is a good place to start. Looking at the logged result code and the code in audiotrack_stream_init, it is failing at the sample format check here: http://hg.mozilla.org/mozilla-central/file/tip/media/libcubeb/src/cubeb_audiotrack.c#l302 That implies that the code is being built with float format samples, but the Android audio backends assume/require sint16 format samples. The logic for that is in configure.in (look for MOZ_SAMPLE_TYPE_S16).
So, the thing here is that we decide in configure.in if we choose integers or floats for audio processing based on the CPU architecture. The actual right thing to do is to choose over the OS_TARGET variable, because our audio backends only work properly with integers.
Attachment #760628 - Flags: review?(blassey.bugs)
Comment on attachment 760628 [details] [diff] [review] Choose between integers or float based on the platform rather than the CPU architecture. r= Review of attachment 760628 [details] [diff] [review]: ----------------------------------------------------------------- ::: configure.in @@ +5361,5 @@ > AC_SUBST(MOZ_WEBRTC_ASSERT_ALWAYS) > AC_SUBST(MOZ_SCTP) > AC_SUBST(MOZ_SRTP) > > +dnl Use integers over floats for audio on B2G and Android just add that the Android and b2g backends don't support floats to the comment
Attachment #760628 - Flags: review?(blassey.bugs) → review+
Comment on attachment 760628 [details] [diff] [review] Choose between integers or float based on the platform rather than the CPU architecture. r= Let's land for Aurora/Beta once this has greened up on m-c.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5eb3a09775c9 and https://hg.mozilla.org/integration/mozilla-inbound/rev/172b542f51ba, because for some reason I forgot to address Brad's comment before pushing.
THANK YOU !!!!! Am so impressed with how quickly the moz team looked into this and found a fix. Applied 5eb3a09775c9 as a patch to todays mozilla-central and did clean build and audio works fine again on my test devices, using youtube videos as tests.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Verified fixed on: Build: Firefox for Android 23.0b10(2013-07-29) Device: ZTE x86 OS: Android 4.0.4
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.