Comment 8 for bug 1478506

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.