Closed Bug 1019949 Opened 10 years ago Closed 10 years ago

Audio continues to play for suspend operation during youtube streaming

Categories

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

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 971414

People

(Reporter: tkundu, Unassigned)

Details

(Whiteboard: [caf priority: p2][CR 672617]) 

Audio continues to play in the background even after suspending the youtube streaming session using power key.

Steps to reproduce the issue:

1) Connect to WIFI network
2) Launch browser and open youtube.com
3) Press power key to disable display and wait 1 min.
4) Unblank display by pressing power key again

Actual behavior: Screen goes blank, but audio continues...when we resume, we see video playing and seek bar has moved during the suspend session.

Expected behavior: Video should pause and audio should stop playing. When we resume, video should play only after we hit play button again

Issue is present in ICS , JB and KK based FFOS .
blocking-b2g: --- → 1.4?
QA Wanted to check 1.3.
Component: General → Video/Audio
Keywords: qawanted
Product: Firefox OS → Core
Version: unspecified → 30 Branch
The audio continues to play while the screen is locked on 1.3 as well.

Environmental Variables:
Device: Buri 1.3
Build ID: 20140602024006
Gaia: 5bd226b03a2d63dfe9df204f7c0afb9984e8fd42
Gecko: 14b755c65af8
Version: 28.0 (1.3) 
Firmware Version: v1.2device.cfg
Keywords: qawanted
QA Contact: lmauritson
Can we confirm this on 1.4 on Flame?
Keywords: qawanted
(In reply to Tapas Kumar Kundu from comment #0)
> Issue is present in ICS , JB and KK based FFOS .
Just for more clarification, this means that this issue is present in FFOS 1.2, 1.3 and 1.4 .
Keywords: qawanted
This is a long standing issue that YT is not concerned with, so this is not a blocker.
blocking-b2g: 1.4? → backlog
Whiteboard: [CR 672617] → [caf priority: p1][CR 672617]
(In reply to Jason Smith [:jsmith] from comment #5)
> This is a long standing issue that YT is not concerned with, so this is not
> a blocker.

Can you point to the existing issue if its already been discussed?
> This is a long standing issue that YT is not concerned with, so this is not
> a blocker.

This argument does not make sense. If an issue has been long standing then we should try to fix it asap instead of keep kicking it further down the road.
It's a common use case and can annoy users. Considering that it works fine on comparable platforms, we should try to fix it for FxOS too.

If not 1.4, can we consider it for 2.0?
blocking-b2g: backlog → 2.0?
Whiteboard: [caf priority: p1][CR 672617] → [caf priority: p2][CR 672617]
Please help with response on Comment #6.

Jet,

Can you please help analyze next steps here. Risk analysis is preferred.
Flags: needinfo?(jsmith)
Flags: needinfo?(bugs)
Jason, this looks like a dupe to me. I feel like we saw this bug during triage a few weeks ago?
And... the UX is pretty simple here: Audio and video should stop if video is stopped. Audio should not continue to play, as stated in the expected behavior in this bug description.
I don't have the bug off the top of my head.
Flags: needinfo?(jsmith)
The YouTube HTML5 video player behavior on desktop is to suspend audio/video playback on sleep and resume immediately on wake. It sounds like we'd want to emulate the desktop behavior in this case. Eric, can you comment on fix risk here?
Flags: needinfo?(bugs) → needinfo?(echou)
Hi, Jenny

According to UX's perspective, do you have any suggestion about this?
Flags: needinfo?(echou) → needinfo?(jelee)
(In reply to Star Cheng [:scheng] from comment #13)
> Hi, Jenny
> 
> According to UX's perspective, do you have any suggestion about this?

Hello Star, for 2.0, when screen is off, stop audio/video playing from web page. Tks!
Flags: needinfo?(jelee)
(In reply to Jenny Lee from comment #14)
> (In reply to Star Cheng [:scheng] from comment #13)
> > Hi, Jenny
> > 
> > According to UX's perspective, do you have any suggestion about this?
> 
> Hello Star, for 2.0, when screen is off, stop audio/video playing from web
> page. Tks!


Hi, Jonas

According to Jenny's suggestion, audio/video streaming from web site should be paused while the screen off. And the behavior is as the same as iOS 7. If we want *not* to pause audio streaming, maybe the service provider can provide the app to achieve that. Could you please give some suggestion about this.
Flags: needinfo?(jonas)
The current behavior was very intentional.

The reason we behave as we do is to enable the user to use websites, that do not have a dedicated FirefoxOS app, as music players.

This was on request from Telefonica, and was designed together with the codeaurora team.
Flags: needinfo?(jonas)
(In reply to Jonas Sicking (:sicking) from comment #16)
> The current behavior was very intentional.
> 
> The reason we behave as we do is to enable the user to use websites, that do
> not have a dedicated FirefoxOS app, as music players.
> 
> This was on request from Telefonica, and was designed together with the
> codeaurora team.

Could you provide the bug number about this for reference?
Flags: needinfo?(jonas)
Ok, thanks.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Sorry - when was this UX decided with the partner, given that the UX team disagrees with maintaining this behavior? I can then follow up with them since this is poor UX and is not in our specs.
Echo to Stephany. 
IMO, it is not a good user behavior. In some use cases some people may want to continue playing audio, but more users (should be over 50% I think) expect the audio from video streaming should be stopped by pressing the power key. 
One suggestion for this problem is maybe we can put this in the "settings" or other places to let user to manually enable it if he or she wants this behavior. 

Bug 971414 is also similar to this one.
blocking-b2g: 2.0? → ---
Please feel free to reopen the bug if it becomes actionable.
(In reply to Jonas Sicking (:sicking) from comment #16)
> ... was designed together with the codeaurora team.

Well we accepted this limitation for v1.0 with the understanding that it would be fixed in v1.1-ish.
It's really bad for power.
(In reply to Blake Wu [:bwu][:blakewu] from comment #21)
> Echo to Stephany. 
> IMO, it is not a good user behavior. In some use cases some people may want
> to continue playing audio, but more users (should be over 50% I think)
> expect the audio from video streaming should be stopped by pressing the
> power key. 
> One suggestion for this problem is maybe we can put this in the "settings"
> or other places to let user to manually enable it if he or she wants this
> behavior. 
> 
> Bug 971414 is also similar to this one.

Will mark this as Dup of Bug 971414. Can we conclude on the behavior and make the change accordingly.
Resolution: WONTFIX → DUPLICATE
This doesn't seem related to bug 971414, so reopening.

(In reply to Michael Vines [:m1] [:evilmachines] from comment #23)
> Well we accepted this limitation for v1.0 with the understanding that it
> would be fixed in v1.1-ish.

Sorry, I hadn't realized that there was an expectation that this would be changed.

We can't really fix this issue without directly changing the feature that Telefonica requested. I.e. this isn't an implementation issue, but rather a disagreement about what is correct behavior.

I think we need to make sure that a conversation happens between Telefonica and codeaurora to get an agreement on what behavior we want.

> It's really bad for power.

If the user wants the audio to keep playing, for example when it's music that the user is listening to, then we won't be able to put the CPU in sleep mode either way.

If the user doesn't want the audio to keep playing, then it seems likely that they'll turn the screen back on and figure out some way to turn off the audio. Which would mean that the CPU can be put to sleep.


Though there is at least two situations where I agree that this will use extra power.

If the user is away from the device and doesn't hear the audio playing, that would mean that when the screen "times out" we will not be able to put the CPU to sleep when we otherwise would. Potentially we could use a different policy when the screen "times out" from when the user intentionally turns off the screen with the power button. But this seems very surprising and unintuitive for a user that actually wants the audio to keep playing.

Another scenario is that if the audio volume is low enough that the user doesn't hear the audio, the user won't bother to turn the screen back on and turn the audio off. Potentially this could be solved by only allowing the audio to keep playing if it's sufficiently loud. But the cut-off volume would be very arbitrary and not work for everyone.


In general I agree that I don't particularly like this feature. One alternative approach that we debated was to enable the user to opt in to having this happen only on certain websites/apps. But that wasn't a very popular suggestion. But I believe the platform support is now there if we want to do UX experiments.

Our audio policies are generally very complex and hard for users to understand and control. There has been talk about doing an overhaul, but we've not gotten the time to do it so far.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Jonas -- why do you think this bug and bug 971414 are unrelated? Both of these bugs talk about stopping the video stream playback when the device screen is switched off.

BTW, these bugs are specific to handling streaming video and corresponding audio and doesn't affect audio only cases. It seemed like your comments are referring to audio-only streaming cases too which is not the intent of these bugs.

> we need to make sure that a conversation happens between Telefonica and codeaurora to get an agreement on what behavior we want.

CAF has already clarified it's stance (comment 23). Can Moz please drive it with TEF and discuss the power implications, change the requirement and fix this issue?
Ah, you are right. I somehow misread bug 971414. This is indeed a dupe.

I'll try to set up a conversation with TEF.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → DUPLICATE
Michael: To finish out the conversation that was started here, is the main concern that while we are in this state that the app is kept in "visible" mode? And so timers still fire at full rate and animations still run at full frame rate?

Or is the concern that we are leaving the app running at all rather than put the CPU in sleep mode?

We can definitely fix the "visibility mode" issue (we're doing that anyway), so if that's enough then we might be good to go. But obviously that only takes care of a small part of the power usage concern.
Fixing visibility should get us most (all?) of the way here.  IIRC, the fallout bugs we've seen have been due to the app not knowing it's not visible and thus continuing to play audio or performing other deliberate actions that are appropriate while in the foreground and inhibit sleep.  Thanks!
Flags: needinfo?(mvines)
You need to log in before you can comment on or make changes to this bug.