Cannot play videos when a wired headphone is connected

Bug #1504065 reported by Michael Zanetti on 2015-10-08
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Critical
kevin gunn
indicator-sound (Ubuntu)
Critical
Charles Kerr
mediaplayer-app (Ubuntu)
Critical
Arthur Mello
unity8 (Ubuntu)
Critical
Unassigned

Bug Description

When having a wired headset connected to the device, video playback keeps on being paused as soon as playback is started. Looks like some snap-decision notification is shown, but it's too short time to read what it actually says because it disappears again when the playback stops again.

<https://wiki.ubuntu.com/Sound#limits>: "So that both buttons do what you expect and the dialog does not disappear unexpectedly, any role change should be postponed as long as the dialog is up."

Related branches

Michael Zanetti (mzanetti) wrote :
summary: - Cannot play videos when a headphone is attached
+ Cannot play videos when a wired headphone is connected
Michał Sawicz (saviq) on 2015-10-08
affects: mediaplayer-app → indicator-sound
Michael Zanetti (mzanetti) wrote :

Looking at it more closely, turns out this is the high volume warning notification.

Michał Sawicz (saviq) wrote :

It's the snap making you decide whether you're OK with high volume.

I think what might be happening here is that the snap causes a focus change on the media player, which stops playback and causes the active role to change.

Jim Hodapp (jhodapp) wrote :

What device and version of Ubuntu Touch are you using?

Michael Zanetti (mzanetti) wrote :

rc-proposed. reproduced the issue on flo and krillin

Jim Hodapp (jhodapp) wrote :

Thanks, how about the build numbers for each?

Michael Zanetti (mzanetti) wrote :

The build numbers are completely useless as they are independent per channel & device. Just flash the latest rc-proposed on any device of your choice and see this happening

Here's the build number for my krillin in case you still think they're useful: 146

Jim Hodapp (jhodapp) wrote :

They're useful for me as I'll make sure to flash that exact version on that same device. Thanks for reporting the bug.

Matthew Paul Thomas (mpt) wrote :

To expand on Michał's hypothesis...

1. You connect a headset for which the remembered "alert" volume < 85 dBA, but "multimedia" volume > 85 dBA.
2. You start playing a video, so the active audio output role switches from "alert" to "multimedia".
3. Since the "multimedia" volume > 85 dBA, the snap decision appears.
4. Since the video has lost focus, it stops playing.
5. Since the video has stopped playing, the active role switches back to "alert".
6. Since the active audio output role is no longer one with volume > 85 dBA, the snap decision disappears.
7. You're left with nothing but a paused video.

If so, there are a few possible solutions, not mutually exclusive...

(1) Perhaps Ubuntu should clamp all restored volumes to 85 dBA? But that might be annoying if you accidentally unplugged a headset for a couple of seconds, plugged it back in, and had to re-amp the volume.

(2, 5) This particular symptom might be suppressed by merging "alert" and "multimedia", though it might still occur while bug 1485522 is unfixed (apps being allowed to override the system-set multimedia volume). Even if that was fixed too, though, you might get a similar problem if, for example, you had set the "alarm" volume to be greater than 85 dBA. Either the volume warning snap decision would suppress the alarm snap decision, and would immediately disappear because the alarm was no longer playing; or the volume warning wouldn't appear at all, because it couldn't appear until the alarm stopped, at which point it would no longer apply.

(4) It might be reasonable to pause video playback when a dialog appears in *some* cases -- for example, incoming call, alarm, or timer done. I doubt this is always true, though -- probably not for volume warnings, and certainly not for dialogs in general on a PC. Pause if you switch to a different app, sure, but not merely for a dialog on top of the current app.

(7) If video playback does pause for a dialog in general, maybe it should resume when the dialog goes away. But that seems unlikely; if loud music was interrupted by a 40-minute phone call, the call unexpectedly disconnecting shouldn't cause the music to suddenly blare in your ears. Anyway, changing that wouldn't fix this bug, it would just make it even worse by turning it into an endless loop.

Sebastien Bacher (seb128) wrote :

Confirmed here on a bq device with ota8 while trying to reproduce bug #1502756, if the notification is displayed it goes in a fight with the player and prevent you playing the video.

It might be worth getting on the next ota list because it makes it quite difficult to play a video with a headphone, which is a think commuters/travelers do often

affects: mediaplayer-app → mediaplayer-app (Ubuntu)
no longer affects: mediaplayer-app
Changed in mediaplayer-app (Ubuntu):
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mediaplayer-app (Ubuntu):
status: New → Confirmed
Changed in unity8 (Ubuntu):
status: New → Confirmed
Changed in canonical-devices-system-image:
importance: Undecided → High
milestone: none → ww02-2016
status: New → Confirmed
assignee: nobody → kevin gunn (kgunn72)
Bill Filler (bfiller) wrote :

I'm bumping this to critical as you literally cannot play a video with the headphones on. The app is responding to active/inactive signals and is getting an inactive signal when the high volume dialog is being displayed, which causes it to pause. This dialog needs to

1) stay on top of the video so the user can press ok
2) not cause an inactive signal to go to the app.

Changed in mediaplayer-app (Ubuntu):
assignee: nobody → Arthur Mello (artmello)
Changed in canonical-devices-system-image:
importance: High → Critical
Changed in unity8 (Ubuntu):
importance: Undecided → Critical
assignee: nobody → Michał Sawicz (saviq)
Changed in mediaplayer-app (Ubuntu):
importance: High → Critical
Michał Sawicz (saviq) wrote :

IMO the high volume snap should not go away just because the video got paused. For this, indicator-sound has everything it needs in its hands. The headphones + playback + high volume should be a trigger for the dialog, not a state.

The correct workflow in this case is, IMO:
- user presses volume up
- sound indicator triggers the high volume warning without changing volume
- video gets paused, because you can't see it (at least on the phone with current design)
\ - user cancels the dialog
  - volume level remains
\ - user accepts the dialog
  - volume is increased
- media player gets focused
- playback should resume (?)

Whether that's universally true for all dialogs, like Matthew pointed out - maybe not. We currently have no way of discerning which dialog should cause that, and which should not.

Matthew Paul Thomas (mpt) wrote :

By "no way of discerning" you mean it's a matter of taste, right? For example, you would choose to pause video for the high-volume warning dialog, whereas I would not. And even if that was a good reason to pause video, it would be much less of a good reason to pause music, which might have caused the same dialog to appear.

Earlier this year, for reasons too comical to explain here, I had to collect examples of dialogs that don't belong to a particular app. (Some of these are currently jury-rigged as snap decisions, others not implemented in Ubuntu Touch at all yet.) It's not necessarily a good idea to let dialogs choose whether to pause video behind them or not. But *if* they could do that, this is what I'd choose for the examples I collected:
- high volume warning -- don't pause
- Wi-Fi authentication -- pause
- "Connect to Hidden Network" -- pause
- "Wi-Fi Available" -- pause
- proxy re-authentication -- pause
- choosing what to do with inserted media -- don't pause
- critically low battery -- pause
- disk space/health warning -- pause
- error reporting -- don't pause
- incoming call -- pause

So if it's better overall to have a single behavior for every dialog, I guess that behavior should be pausing. But the larger the screen size, the less sense that will make. And regardless of those answers for video, my answer would be "don't pause" for all of them with audio.

All that aside, if you say the dialog should pause video, well, it's already doing that, so the problem remains unsolved. We need to make sure the dialog stays visible *despite* the video pausing. Given that there will always be more than one audio role, role switching will always be a possibility, so we seem to have two options. The first is to switch the role as usual, but persist the alert referring to a role that the volume buttons are no longer controlling; but that would be incoherent. The other is to delay any role change for as long as the dialog is up. Specification updated. <https://wiki.ubuntu.com/Sound?action=diff&rev2=163&rev1=162>

description: updated
Michael Zanetti (mzanetti) wrote :

Please forgive my ignorance, but do we really need to show a notification with confirmation buttons? Isn't the volume progress bar turning orange and having a warning message enough of a warning? While I have seen such high volume notifications on iPhones, I don't think I ever had to press a button to confirm that I want to hurt my ears.

W dniu 03.12.2015 o 12:15, Matthew Paul Thomas pisze:
> By "no way of discerning" you mean it's a matter of taste, right?

No, actually, no means for the originator of the dialog to communicate
whether the desire is to pause or not. Not saying it's impossible to
add, just more throw-away work in soon-to-be reimplemented
notification/dialog area.

What's more, it's not the dialog, nor the shell, that decides to pause
the video or not. It's the media player that does, because it's been
unfocused. Do you believe that some dialogs should change focus, some
shouldn't?

> For
> example, you would choose to pause video for the high-volume warning
> dialog, whereas I would not. And even if that was a good reason to pause
> video, it would be much less of a good reason to pause music, which
> might have caused the same dialog to appear.

Sure, music doesn't pause when the app is unfocused, so we're good there.

> Earlier this year, for reasons too comical to explain here, I had to collect examples of dialogs that don't belong to a particular app. (Some of these are currently jury-rigged as snap decisions, others not implemented in Ubuntu Touch at all yet.) It's not necessarily a good idea to let dialogs choose whether to pause video behind them or not. But *if* they could do that, this is what I'd choose for the examples I collected:
> - high volume warning -- don't pause
> - Wi-Fi authentication -- pause
> - "Connect to Hidden Network" -- pause
> - "Wi-Fi Available" -- pause
> - proxy re-authentication -- pause
> - choosing what to do with inserted media -- don't pause
> - critically low battery -- pause
> - disk space/health warning -- pause
> - error reporting -- don't pause
> - incoming call -- pause
>
> So if it's better overall to have a single behavior for every dialog, I
> guess that behavior should be pausing. But the larger the screen size,
> the less sense that will make.

Here, too, the question is what should the media player app do when it's
unfocused - some would argue they'd want the video continue to play even
on a phone when they've switched to a different app. Certainly true on
the desktop.

> And regardless of those answers for
> video, my answer would be "don't pause" for all of them with audio.

Agreed.

> All that aside, if you say the dialog should pause video, well, it's
> already doing that, so the problem remains unsolved. We need to make
> sure the dialog stays visible *despite* the video pausing. Given that
> there will always be more than one audio role, role switching will
> always be a possibility, so we seem to have two options. The first is to
> switch the role as usual, but persist the alert referring to a role that
> the volume buttons are no longer controlling; but that would be
> incoherent. The other is to delay any role change for as long as the
> dialog is up. Specification updated.
> <https://wiki.ubuntu.com/Sound?action=diff&rev2=163&rev1=162>

Works for me.

Pat McGowan (pat-mcgowan) wrote :

@michael this is actually a legal requirement we implemented for bug #1373404 and defined at
https://wiki.ubuntu.com/Sound#High_volume_limits_and_warnings

Michael Zanetti (mzanetti) wrote :

From: http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32009D0490&rid=1

"Personal music players shall provide adequate warnings on the risks involved in using the device and to the ways of avoiding them and information to users in cases where exposure poses a risk of hearing damage."

IANAL, but 1 warning text and some alerting color for the volume progress bar seems adequate to me and for all the other music player manufacturers too. Since that law passed in 2009 I haven't ever had to confirm an intrusive popup somewhere. If possible, I would probably still consider getting rid of the focus stealing popup altogether.

Changed in indicator-sound:
assignee: nobody → Xavi Garcia (xavi-garcia-mena)
Changed in indicator-sound:
assignee: Xavi Garcia (xavi-garcia-mena) → Charles Kerr (charlesk)
Alejandro J. Cura (alecu) wrote :

Michael: I don't know about specific media players, but mobile operating systems do something similar to what we do:

Android has such a popup dialog: https://lh3.googleusercontent.com/-w7eI7XSyGeA/ULSub0P_5HI/AAAAAAAAYBA/WBSCTnj1vwQ/s518/2012+-+1

Windows 10 as well: http://superuser.com/questions/991638/how-to-disable-high-volume-warning-dialog

IOS seems by default to not allow going over the value required by the law, but there's a toggle to disable it in the settings: http://www.head-fi.org/t/635993/lightbox/post/8863328/id/719624

Matthew Paul Thomas (mpt) wrote :

The relevant bit from the regulation, as quoted in the spec, is "Provide a means to actively inform the user of the increased sound pressure ... Any means used shall be acknowledged by the user". Tapping a button in a dialog is acknowledgement by the user. Toggling a settings switch, ahead of time, would arguably be acknowledgement by the user (I'd want to check with a lawyer first). But maybe or maybe not noticing that the volume gauge is a different color is not acknowledgement by the user.

"What's more, it's not the dialog, nor the shell, that decides to pause the video or not. It's the media player that does, because it's been unfocused. Do you believe that some dialogs should change focus, some shouldn't?"

I'd happily answer in detail, but that issue seems to be four steps removed from fixing this bug. First, focus and layering are not the same thing. Focus stealing prevention is important, but on phones Unity might need to layer dialogs in front even when denying them focus, because -- unlike on PCs -- it can't rely on the Launcher to show you that they've opened. All my examples assume the dialogs will be in front, but not necessarily focused.

Second, even if being unfocused was a reliable indicator of being in the background, that would be a highly questionable reason to pause video. For example, it would be annoying to pause music merely because the player is in the background -- but currently, 40% of music listening is done on YouTube, and is therefore video.

Third, regardless of whether being in the background is a good reason to pause video, individual media-playing apps seem like the wrong place to make that decision. For example, a phone call should pause video, and pause music, and mute any other multimedia audio, in every app, when the call rings. Does that mean every media-playing app should contain code for pausing on phone calls? Of course not; app developers would usually not know, not remember, or not bother. It's a job for the media frameworks, not the apps.

And fourth, even if apps were responsible for pausing video, I don't think that pausing should have any effect on the volume warning dialog. I think that's the root problem, and the reason for my spec change above: as long as the dialog is up, audio pausing shouldn't change the active output role and therefore shouldn't dismiss the dialog.

Michał Sawicz (saviq) wrote :

W dniu 06.12.2015 o 19:59, Matthew Paul Thomas pisze:
> "What's more, it's not the dialog, nor the shell, that decides to pause
> the video or not. It's the media player that does, because it's been
> unfocused. Do you believe that some dialogs should change focus, some
> shouldn't?"
>
> I'd happily answer in detail, but that issue seems to be four steps
> removed from fixing this bug. First, focus and layering are not the same
> thing. Focus stealing prevention is important, but on phones Unity might
> need to layer dialogs in front even when denying them focus, because --
> unlike on PCs -- it can't rely on the Launcher to show you that they've
> opened. All my examples assume the dialogs will be in front, but not
> necessarily focused.

What's the difference between a focused and an unfocused dialog, when
it's in front in both cases?

> Second, even if being unfocused was a reliable indicator of being in the
> background, that would be a highly questionable reason to pause video.
> For example, it would be annoying to pause music merely because the
> player is in the background -- but currently, 40% of music listening is
> done on YouTube, and is therefore video.

We don't support such a use case on the phone today, and while I'd argue
there's a need for an app that would do that for you (ignore the video
stream to save bandwidth and battery), I do get we need to think of such
a use case. Don't have a good answer how to behave here, though.

> Third, regardless of whether being in the background is a good reason to
> pause video, individual media-playing apps seem like the wrong place to
> make that decision. For example, a phone call should pause video, and
> pause music, and mute any other multimedia audio, in every app, when the
> call rings. Does that mean every media-playing app should contain code
> for pausing on phone calls? Of course not; app developers would usually
> not know, not remember, or not bother. It's a job for the media
> frameworks, not the apps.

Indeed, and that's how it works today, all multimedia streams are paused
when a stream plays in the "ringtone" role, such as an incoming call.
Whether the same should apply for incoming SMS is questionable, so it's
not as easy as "when there's a ringtone, pause", so we'll need more
smarts here still.

> And fourth, even if apps were responsible for pausing video, I don't
> think that pausing should have any effect on the volume warning dialog.
> I think that's the root problem, and the reason for my spec change
> above: as long as the dialog is up, audio pausing shouldn't change the
> active output role and therefore shouldn't dismiss the dialog.

Full agreement here.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in indicator-sound (Ubuntu):
status: New → Confirmed
affects: indicator-sound → indicator-sound (Ubuntu)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in indicator-sound (Ubuntu):
status: New → Confirmed
Charles Kerr (charlesk) on 2015-12-29
Changed in indicator-sound (Ubuntu):
importance: Undecided → Critical
status: Confirmed → In Progress
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
Michał Sawicz (saviq) on 2016-01-14
Changed in unity8 (Ubuntu):
status: Confirmed → Won't Fix
assignee: Michał Sawicz (saviq) → nobody
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package indicator-sound - 12.10.2+16.04.20160113.1-0ubuntu1

---------------
indicator-sound (12.10.2+16.04.20160113.1-0ubuntu1) xenial; urgency=medium

  [ Charles Kerr ]
  * Be more selective about when to show and dismiss the High Volume
    Warning Dialog. (LP: #1504065)

  [ charles kerr ]
  * Be more selective about when to show and dismiss the High Volume
    Warning Dialog. (LP: #1504065)

 -- Charles Kerr <email address hidden> Wed, 13 Jan 2016 20:37:58 +0000

Changed in indicator-sound (Ubuntu):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers