Default audio role for volume controls isn't the role that sound effects use

Bug #1498466 reported by Matthew Paul Thomas
38
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
High
John McAleely
qtubuntu-media (Ubuntu)
Triaged
Undecided
Unassigned

Bug Description

1. Play a game that just plays occasional sound effects, not music.
2. Try to change the volume of the sound effects.

What should happen: You can.
What actually happens: You can't unless you time it exactly right, pressing the volume controls while the sound effect is playing.

For brief sounds (less than a second or so), like sound effects in a game or a messaging app, you probably won't be fast enough to change their volume while they're playing. So, you need to be able to change their volume even when they aren't playing.

If you want to be able to do this with the hardware volume buttons, that means that by default (when no sound is playing), the hardware volume buttons should control the role that sound effects use.

So, the current design is that this default role for volume controls should be "alert", and that sound effects should use "alert". <https://wiki.ubuntu.com/Sound#primary-output>

Unfortunately, this doesn't work at the moment because the Qt SoundEffect API <http://doc.qt.io/qt-5/qml-multimedia.html#soundeffect> produces sounds that do not use the "alert" role, but rather "multimedia". Because this is not the default role, the hardware volume buttons control the volume of sound effects only during the brief moments when the sound effects are actually playing, which is unhelpful.

Some possible ways to resolve this bug:

A. Decide that you should not, in fact, be able to change the volume of sound effects using the hardware buttons when sound effects aren't playing. Drawback: Annoying.

B. Change the SoundEffect API implementation so that it uses the "alert" role by default. Drawback: You couldn't silence sound effects without silencing the ringtone too. (Unless the ringtone was moved to a different role.)

C. Change the default role to "multimedia". Drawback: Not clear what "alert" would actually include any more.

D. Combine the "alert" and "multimedia" roles. Drawback: You couldn't change sound effect volume independent of music that was playing in the background (but maybe that's not a big deal).

<https://wiki.ubuntu.com/Sound#role>: "Setting the role to alert should be functionally identical to setting it to multimedia. This is so that you can both change the volume of alerts even when they are not currently playing, and change the volume of other sound effects even when they are not currently playing."

(This is a followup to bug 1478506.)

Tags: volume
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in qtubuntu-media (Ubuntu):
status: New → Confirmed
Revision history for this message
Jim Hodapp (jhodapp) wrote :

Shouldn't there be another option that would include an explicit volume control for sound effects in Ubuntu System Settings? This is basically what iOS does - although it combines the ringer and alerts volumes as one, but it does have a manual way of setting this volume from the setting app and even changing whether the hardware buttons control this level or not.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Specifically, iOS's "Ringer and alerts" slider is followed by a "Change with Buttons" switch. When off, it has a caption: "The volume of the ringer and alerts will not be affected by the volume buttons." When on, the caption is: "The volume of the ringer and alerts can be adjusted using the volume buttons."

Until now I had never understood this setting, because none of that text answered the vital question: What is the effect of the off state? When the switch is off, what *do* the volume buttons adjust? From testing it now, it seems that when it's off, the volume buttons always change media volume. When it's on, the volume buttons change media volume when media is playing, ringer/alert volume when media isn't playing, like the specced-but-unimplemented Ubuntu behavior.

Anyway, I don't think System Settings is relevant to this bug, because you shouldn't have to switch to System Settings and back while playing a game.

Revision history for this message
Jim Hodapp (jhodapp) wrote : Re: [Bug 1498466] Re: Default audio role for volume controls isn't the role that sound effects use
Download full text (3.9 KiB)

On Tue, Sep 29, 2015 at 12:59 PM, Matthew Paul Thomas <email address hidden>
wrote:

> Specifically, iOS's "Ringer and alerts" slider is followed by a "Change
> with Buttons" switch. When off, it has a caption: "The volume of the
> ringer and alerts will not be affected by the volume buttons." When on,
> the caption is: "The volume of the ringer and alerts can be adjusted
> using the volume buttons."
>
> Until now I had never understood this setting, because none of that text
> answered the vital question: What is the effect of the off state? When
> the switch is off, what *do* the volume buttons adjust? From testing it
> now, it seems that when it's off, the volume buttons always change media
> volume. When it's on, the volume buttons change media volume when media
> is playing, ringer/alert volume when media isn't playing, like the
> specced-but-unimplemented Ubuntu behavior.
>
> Anyway, I don't think System Settings is relevant to this bug, because
> you shouldn't have to switch to System Settings and back while playing a
> game.
>

I agree, I was thinking more along the lines of you set the alert volume
ahead of time that would be good, but I agree, if it's too loud for a given
context this is problematic. I did, however, just notice on iOS that a game
uses the same volume level as the music playback level. If you're in a game
and set the volume, then switch back to the music app, the music app uses
this new volume. This is exactly how it should be for Ubuntu Touch.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1498466
>
> Title:
> Default audio role for volume controls isn't the role that sound
> effects use
>
> Status in Canonical System Image:
> New
> Status in qtubuntu-media package in Ubuntu:
> Confirmed
>
> Bug description:
> 1. Play a game that just plays occasional sound effects, not music.
> 2. Try to change the volume of the sound effects.
>
> What should happen: You can.
> What actually happens: You can't unless you time it exactly right,
> pressing the volume controls while the sound effect is playing.
>
> For brief sounds (less than a second or so), like sound effects in a
> game or a messaging app, you probably won't be fast enough to change
> their volume while they're playing. So, you need to be able to change
> their volume even when they aren't playing.
>
> If you want to be able to do this with the hardware volume buttons,
> that means that by default (when no sound is playing), the hardware
> volume buttons should control the role that sound effects use.
>
> So, the current design is that this default role for volume controls
> should be "alert", and that sound effects should use "alert".
> <https://wiki.ubuntu.com/Sound#primary-output>
>
> Unfortunately, this doesn't work at the moment because the Qt
> SoundEffect API <http://doc.qt.io/qt-5/qml-
> multimedia.html#soundeffect> produces sounds that use do not use the
> "alert" role, but rather "multimedia". Because this is not the default
> role, the hardware volume buttons control the volume of sound effects
> only during the brief moments when...

Read more...

description: updated
Changed in canonical-devices-system-image:
assignee: nobody → John McAleely (john.mcaleely)
importance: Undecided → High
milestone: none → backlog
status: New → Confirmed
Changed in canonical-devices-system-image:
milestone: backlog → ww08-2016
tags: added: volume
Revision history for this message
Matthew Paul Thomas (mpt) wrote :
description: updated
Changed in qtubuntu-media (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

This could be due to the general issue with audio roles not working as designed

Changed in canonical-devices-system-image:
assignee: John McAleely (john.mcaleely) → Michał Sawicz (saviq)
Revision history for this message
Jim Hodapp (jhodapp) wrote :

@mpt: Is the update to the specification that you made the final solution for this issue? Is it ready to be implemented then and no more need for discussion?

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Michał and I have been e-mailing about alternative approaches, but none so far that solve the original problem of the volume buttons being unhelpful in this situation.

When I wrote that it maintains “forward compatibility if we distinguish [the roles] in future”, I meant that it lets us change our approach if it turns out not to work. This is a hard problem involving unpredictable behavior of app developers, so we can’t be sure that anything will work unless we try it. Is this the final solution? I don’t know. Is it ready to be implemented? I think so, yes.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

FWIW, Android apparently has exactly the same issue: volume buttons control the active audio stream if there is one, and the ringer if there isn’t, which is awkward if an app frequently plays sound but isn’t right now. Their solution is for those kinds of app to call a “setVolumeControlStream()” function when they launch. <https://developer.android.com/training/managing-audio/volume-playback.html> I guess the benefit is that they keep the distinct roles; the drawback is that different apps, maybe unexpectedly, behave in different ways.

Michał Sawicz (saviq)
Changed in canonical-devices-system-image:
assignee: Michał Sawicz (saviq) → John McAleely (john.mcaleely)
milestone: ww08-2016 → 11
Changed in canonical-devices-system-image:
milestone: 11 → backlog
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers