Closed Bug 761936 Opened 13 years ago Closed 13 years ago

Audio doesn't stop playing when out-of-process app is "closed"

Categories

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

Product:
Core
Component:
Audio/Video
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Project Flags:
blocking-basecamp +

People

(Reporter: cjones, Assigned: kinetik)

References

Details

(Keywords: qawanted)

STR (1) Load PenguiPop app out-of-process in current gaia. (2) Use the task switcher to "close" it. The game's audio continues to play after it's "closed". We're probably not destroying the iframe hard enough, or it's not tickling the right thing in gecko. Filing in b2g for now, but might be a more general platform issue. (The underlying problem here might be leading to other issues as well.)
Sorry, s/PenguiPop/Cut the Rope/. We're definitely destroying the iframe when we expect to [time:1339070413288758][PBrowserParent] Sending Msg_Destroy([TODO]) [time:1339070413289410][PBrowserChild] Received Msg_Destroy([TODO]) [time:1339070413292247][PLayerChild] Sending Msg___delete__([TODO]) [time:1339070413292675][PLayersChild] Sending Msg___delete__([TODO]) [time:1339070413292891][PRenderFrameChild] Sending Msg___delete__([TODO]) [time:1339070413293088][PBrowserChild] Sending Msg___delete__([TODO]) [time:1339070413304502][PLayerParent] Received Msg___delete__([TODO]) [time:1339070413304842][PLayersParent] Received Msg___delete__([TODO]) [time:1339070413304949][PRenderFrameParent] Received Msg___delete__([TODO]) [time:1339070413305052][PBrowserParent] Received Msg___delete__([TODO]) everything that needs to shut down shuts down. But we keep sending audio data for *quite* a while, another 40 seconds or so, and finally DrainDone() [time:1339070460966412][PAudioParent] Sending Msg_PositionInFramesUpdate([TODO]) [time:1339070460966921][PAudioChild] Received Msg_PositionInFramesUpdate([TODO]) [time:1339070461888392][PAudioParent] Sending Msg_DrainDone([TODO]) [time:1339070461888766][PAudioChild] Received Msg_DrainDone([TODO]) Definitely a gecko problem. Apparently works in xul-fennec on android, which is rather suspicious ...
Component: General → Video/Audio
Product: Boot2Gecko → Core
QA Contact: general → video.audio
Possibly the gonk audio backend for libsydneyaudio? Anyone doing a libcubeb gonk backend?
I'm hoping it's something dumber than that, but maybe.
This sounds like bug 695612, but I don't know why it wouldn't be showing up in xul-fennec too.
I think the options we have here are 1. Have content processes directly talk to mediaserver on Gonk. This is most expedient. That's not horribly bad, but means that we increase the surface area of OS that content processes touch for no particular reason. (We don't vouch for mediaserver security-wise.) This will also pretty much kill off the sandboxed audio backend for the time being. 2. Fix bug 695612. That's not hard at all. 3. Make the proxying audio backed use cubeb(?). (And make the Gonk backend use cubeb?) I'm not entirely sure what this approach entails. Media folks, thoughts?
blocking-basecamp: --- → +
Depends on: 695612
Matthew, please take this ...
Assignee: nobody → kinetik
This should already be fixed if bug 695612 was the root cause. If someone with a current build can test and let me know, that'd be great.
Keywords: qawanted
Will check and update bug this aft
David Clarke has said he'll take this on since it related to his media testing.
Just to follow up: have the 07/24/2012 build running on otoro device. Cut The Rope App, when loading reports basically a 404 that the dns entry cuttherope could not be found. Music App Doesn't recognize local Storage. Video App has the same problem. So we are in a bit of flux.
QA Contact: dclarke
Do we have any other way to reproduce this? Chris?
How are we doing here?
Priority: -- → P1
I think the open question is whether there is another way to reproduce this bug? I believe the only
I think the open question is whether there is another way to reproduce this bug? When I load the cut the rope app, there are quite a few parse errors in logcat, and then the application fails. Device Storage is still a blocker for me, however It looks like the bug has a patch. John any ideas as to how to reproduce this?
Open the browser. Navigate to a web page with audio (eg. http://cd.pn/a). Start playing. Switch away from the browser and then close it using the task switcher. Does the audio continue?
This was verifed over the weekend as 777259 got committed. Audio stops as expected.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.