Apps change volume all the time

Bug #1478506 reported by Michael Zanetti on 2015-07-27
36
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Alejandro J. Cura
indicator-sound (Ubuntu)
High
Xavi Garcia
pulseaudio (Ubuntu)
Undecided
Unassigned

Bug Description

To reproduce, install the app "Maroon in trouble" from the app store and play it a little with having sound enabled. Press the volume down hardware button on the phone. It will temporarily decrease the volume. However, whenever a new item comes into the scene, it will be on 100% volume again.

Setting the system volume to 0 should keep everything at 0.

Please note that this app does *not* have any code to set the volume! Also this app is one of the upstream Qt QML example demo apps, so this is really how QML apps are supposed to work (in other words, it is not a badly implemented app, but really an issue in the system)

Related branches

Michał Sawicz (saviq) wrote :

Related: bug #1478075

Launchpad Janitor (janitor) wrote :

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

Changed in indicator-sound (Ubuntu):
status: New → Confirmed
Pat McGowan (pat-mcgowan) wrote :

@charles can you do some research

Changed in indicator-sound (Ubuntu):
assignee: nobody → Charles Kerr (charlesk)
dinamic (dinamic6661) wrote :

same thing happens with machines vs machines :P (i have to mute the app to play it @ night)

Changed in canonical-devices-system-image:
status: New → Confirmed
Charles Kerr (charlesk) wrote :

@pat, xavi's going to be look into some of the indicator-sound backlog, including this ticket

Changed in indicator-sound (Ubuntu):
assignee: Charles Kerr (charlesk) → Xavi Garcia (xavi-garcia-mena)
Changed in canonical-devices-system-image:
assignee: nobody → Alejandro J. Cura (alecu)
importance: Undecided → High
milestone: none → ww40-2015
Changed in indicator-sound (Ubuntu):
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

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

Changed in pulseaudio (Ubuntu):
status: New → Confirmed
Matthew Paul Thomas (mpt) wrote :

I think there are two possibilities here.

One is that this is merely a duplicate of bug 1418210: volume level is reset "anytime a new QAudioOutput is created",

The other is that we have our output roles muddled. I was told that the default role for sound output -- not alarms, not phone calls, and not media playback, but anything else -- was called "alert". So I specified that the volume controls should default to controlling the "alert" volume, switching to another role temporarily only when that other role is being used. <https://wiki.ubuntu.com/Sound?action=diff&rev2=137&rev1=136> Alarms, phone calls, and media playback almost always last for more than a couple of a seconds, so you have time to change their volume.

But if apps are -- or whatever audio API apps use is -- by default using some output role that is *not* "alert", then we'd see pretty much what's described here: the volume controls switch to showing that other role, but it's usually too brief for you to change the volume before the control reverts to showing the alert volume. So it *looks* like apps are changing the volume themselves, when really they're just using an output role that you usually don't see the volume of and don't have time to change the volume of.

As well as being annoying in itself, the existence of this bug is causing confusion in other bug reports about sound volume UI, particularly bug 1389761, bug 1396986, and bug 1478075.

Matthew Paul Thomas (mpt) wrote :

It seems as if there aren't two problems here after all ... There are three.

First, if you are quick enough to change the volume while a sound effect is playing, you can see that it resets to the maximum the next time the sound effect plays. That's bug 1418210.

Second, even if you don't do that, if headphones are connected, you still get volume notifications from the output role changing. That makes *this* bug much easier to notice (otherwise the only effect would be that the hardware keys seemed like they didn't work), but it's nonetheless separate, so I've reported it as bug 1484589.

And third, this bug, that the output role changes too briefly for you to change its volume.

Maroon in Trouble uses the Qt SoundEffect API. <http://doc.qt.io/qt-5/qtquick-demos-maroon-example.html>

Qt says that "SoundEffect provides a way to play short sound effects, like in video games ... You should use Audio for music playback." <http://doc.qt.io/qt-5/qml-multimedia.html#soundeffect>

Apparently SoundEffect is using the "multimedia" role, which is not the "alert" default, which causes a temporary role switch.

So, the way to fix this bug following the current design would be to change SoundEffect in Qt to use the default "alert" role, while Audio continues using the "multimedia" role.

Alternatively, we could change the volume controls to control not simply the active output role, but something like "the active output role unless it was changed less than 5 seconds ago, in which case the previous output role". But I think just fixing SoundEffect would be simpler.

summary: - Apps change system volume all the time
+ Apps change audio output role all the time

I don't think we want to change the SoundEffect to the alert role. That would make things even more complicated and not really help with this bug. Also that would have the side effect that in order to mute a game one has to mute the ringtone, which IMO are really not the same thing.

Also muting a game with some background music and sound effects (e.g. Machines vs. Machines) would require both, the alert and the multimedia slider to be muted.

Xavi Garcia (xavi-garcia-mena) wrote :

The main problem I've found when testing this bug is that every sound played from the "Maroon in trouble" opens and closes the pulse audio sink to play every single sound.
What we experience then is that the role is changing from "alert" to "multimedia" just for less than a second and you can see the sound slider at the indicator moving from 100% to the alert role volume.

You don't have the time to change the volume of the game, because it uses the multimedia role for a very short period of time, and even you modify the multimedia role volume every sound that comes from that game is set to 100% when we read it using pulse.

I have a workaround branch, that stores volumes for every role and set the current volume for the multimedia sink when any sound of that role comes in. I'm not fully convinced by that approach, so I've opened a bug in pulse-audio to see why we get 100% volume for the sounds coming from the game.

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1485522

Oliver Grawert (ogra) wrote :

If we would have a volume-slider Qt/QML element that allows you to pick the role it manages you could have a volume control in the app (like i described in bug #1389761) ...
that would indeed not fix indicator sound (or volume button) behaviour unless you limit its focus to certain roles.

Matthew Paul Thomas (mpt) wrote :

"I don't think we want to change the SoundEffect to the alert role. That would make things even more complicated and not really help with this bug."

It's not more complicated, because SoundEffect and Audio *already both exist*. If they are supposed to use the same role, what is the point of them both existing?

I described how it would fix the bug: it would result in SoundEffect using the role that the volume controls are operating on most of the time, and therefore the volume controls would change the volume of the game sounds. Why do you say it would not really help?

"Also muting a game with some background music and sound effects (e.g. Machines vs. Machines) would require both, the alert and the multimedia slider to be muted."

Any game that plays background music should contain its own button for muting the background music, because you might prefer to play your own music in the background instead. This is routine on other platforms, so I think it's quite reasonable to expect for Ubuntu games too.

Michael Zanetti (mzanetti) wrote :

"It's not more complicated, because SoundEffect and Audio *already both exist*. If they are supposed to use the same role, what is the point of them both existing?"

They both are intended for multimedia but the difference is on a technical level.
The Audio element is more suited for music. It provides metadata about the song it plays, reading ID3 tags from mp3 files and the like. This however makes it slow to load. The SoundEffect item instead is for sound effects. It doesn't have all the bells and whistles but is optimized for low latency. Still both are for playing audio in games/apps using the multimedia role.

If the SoundEffect would use the alert role it would be adjusted to the ringtone value. Why would you want that? I don't want to or lower the ringtone of the phone, I want to control the audio of the game. Having Audio and SoundEffect on different roles would be even more confusing as the hardware buttons sometimes would control the game's background music (which is normally using Audio) and sometimes the SoundEffects it plays.

I do agree that games should have in-game volume controls too. But that's quite unrelated. In the end we have two roles, alert (for ringtones of phone calls, SMS etc) and multimedia (music player, games music etc). Both can be controlled with the hardware buttons. This is fine in general, but the current implementation is not good enough. As you've pointed out there are multiple issues.

However, this discussion is getting quite off-topic on the original issue reported in the bug. We should probably continue it on the mailing list.

Matthew Paul Thomas (mpt) wrote :

It's on-topic because changing SoundEffect to the alert role (and fixing bug 1418210, which should be fixed regardless) would fix this bug. The volume hardware buttons would control the volume of the game sound effects. But maybe there's a better solution. So let's step back a bit.

The goal of the audio roles is to minimize the number of times you feel the need to adjust the volume per hour of use. We achieve that by remembering your last preferred volume for different categories of sound. It's a balancing act. The fewer categories we have, the more likely it is that disparate things will share a category, so you'll more often be changing the volume to suit one or the other. On the other hand, the more categories we have, (a) the more you'll feel like the phone is forgetting your choice when really it's just not sharing it widely enough; (b) the more app developers will use the wrong one by mistake; and (c) the more often sounds from multiple categories will be playing at once, so you may get frustrated that the volume buttons affect only one of them and not the other(s).

Then we give those categories a priority order, based mostly on what's likely to be most important to you in that case when multiple categories are playing at once. We put alarm first, because it's relatively uncommon, but you can (if you want to) leave an alarm playing as long as you like while fine-tuning its volume. We put alert last, because it's likely to be short-lived, so (as demonstrated by this bug report) it's not reasonable to expect you to adjust it during the brief period it's playing.

Per spec, we currently have four categories, in order: alarm, phone (for call audio), multimedia, and alert. I think that the alert category should include both game sound effects (because they're often <1s long), and the ringtone (because you're likely to want it to be at the same volume). Drawbacks of this approach:
- Whenever a game is playing music as well, the volume buttons change the volume of the music but not the sound effects.
- Any others?

If the ringtone issue was a problem, we could solve it by putting ringtone into a category all by itself, or moving it to the alarm category: alarm/ringtone, phone call, multimedia, alert. Most/all apps should stop playing audio altogether when the phone is ringing, so the change in order should make little difference. But it would still have the same drawback with apps that play both music and sound effects: the volume buttons will change the former but not the latter.

It seems to me the only way to resolve that drawback would be to put sound effects and music in the same category, as they are now. But that would have a different drawback:
- If you're using an app that plays only sound effects (e.g. each time you send a message), while a different app is playing music, the sound effects will often be too loud, and there's nothing you can do about it short of going into Silent Mode.

I don't see any way to solve all those problems at once, so it's a matter of choosing the least bad.

Michael Zanetti (mzanetti) wrote :

This bug is about an issue in the implementation that whenever someone creates a new "Audio" or "SoundEffect" item (regardless of the role) it will change the volume. The game maroon in trouble, as mentioned in the original bug description only uses SoundEffects, no Audio. Yet it changes the volume all the time. Please do not change the topic for this bug to some role-discussion. We have other bugs for that. I've moved the discussion to the phone mailing list.

summary: - Apps change audio output role all the time
+ Apps change volume all the time
Matthew Paul Thomas (mpt) wrote :

If you weren't pressing the volume buttons at the same time as the sound effects were playing, as you probably weren't, then (once again) changing the role of SoundEffect and fixing bug 1418210/1485522 would fix this bug. But if you're sure that you were pressing the volume buttons while the sound effects were playing, then this is a duplicate of bug 1485522.

Matthew Paul Thomas (mpt) wrote :

I reported bug 1498466 on the problem of the default role not being the one that sound effects use.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers