ubuntu-phone team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Zanetti wrote on 21/09/15 09:30:
> 
> ...
> 
> If you go through launchpad bugs, you'll find lots of bugs related 
> to volume control [1][2][3][4]. Let me summarize it up here:
> 
> The biggest issue is that the volume buttons are completely 
> unpredictable. They control a different volume level each time you 
> touch them. For instance, play some game with a background music, 
> press the volume buttons. It will adjust the game's sound level 
> (maybe, with a bit of luck). Then start the game "Dinosaur" from 
> the store and try again, you'll notice that while playing this game
> the volume buttons don't affect the sound made by the game any more
> but instead they'll leave the game at 100% volume,

This is probably "Volume obtained is 100% in multimedia sink for
sounds from app" <http://launchpad.net/bugs/1485522>.

> while silencing your phone call ringtones. This is the thing that 
> makes me lose phone calls all the time. I play some game with the 
> phone, and when I'm done my ringtones are silenced without me even 
> knowing.

Have you reported the bug of the ringtone being silenced? That seems
like a separate bug from the game volume being set to 100%.

> Another issue is that currently there's not really way to figure 
> what volume level your device is set to. The slider in the 
> indicator is quite meaningless, given it will fool you by 
> displaying some value, but next time a sound is produced it will 
> jump to some different value before playing the sound.

I thought this was what your first cited bug report was about, but you
seem to be sure that it is not, so I've reported it separately.
<http://launchpad.net/bugs/1498466>

> This also creates the issue that there's no way to control your 
> sound level *before* you start a game, means you can't really start
> a game on Ubuntu Touch in a place where you can't make noise,
> because you have no chance to set the volume before it starts
> playing.

In theory, you can go into Silent Mode before you start the game.

In practice, this doesn't work because of a separate problem: Silent
Mode requires care from app developers, but our SDK makes it highly
impractical. It requires care from app developers, because the OS
alone can't tell which sounds should play even in Silent Mode (alarms,
manually-played videos, language-training exercises) and which should
not (ringtones, background music, game cutscenes, sound effects). And
our SDK makes it highly impractical, firstly because we give no hint
how to do it <https://developer.ubuntu.com/en/search/?q=silent+mode>,
and secondly because even if we did, a developer would need to
remember to wrap an
if(getUserValue("com.ubuntu.touch.AccountsService.Sound",
"SilentMode").toBool()){...} or equivalent around every sound that
should not play in Silent Mode -- which, most of the time, they'll
forget to do.
<http://irclogs.ubuntu.com/2015/06/01/%23ubuntu-touch.html#t15:26>

> I've spent some time to figure where the issue is coming from and 
> what a solution could be. The main reason where this issue is 
> coming from is that we have a number of different audio roles that 
> applications are using. The volume buttons, as well as the slider 
> in the indicators try to be clever in knowing which role they 
> should address whenever you touch them. This, however, seems to 
> reliably fail in 99% of the cases you want to use it.

Maybe the roles are the problem, or maybe they aren't. We can't tell,
as long as the three bugs above aren't fixed.

> So here's my proposal:
> 
> * Let's drop all the audio roles we have except for ringtone 
> (alert) and multimedia. We don't need more of them, it'll make 
> things unnecessarily complex.

Proposing to revamp the audio roles here is like camping at night:
you're being bitten by bugs, and it's more frustrating than usual,
because they're bugs you can hear but not see. Your proposed solution
is to replace the tent.

Well, maybe the tent is the problem. But let's try getting rid of the
bugs inside the current tent first.

> * Make the hardware buttons always control the multimedia volume, 
> that is, game sounds, music player etc but don't ever touch 
> ringtone volume with them.

As Alan Pope pointed out, that would mean you couldn't quiet a ringing
phone. Your response was to independently devise one detail of the
current design:
> 
> Probably the hardware buttons should then control ringtone volume 
> while no app is focused (or a call indication is on top) and 
> control the multimedia volume whenever an app is focused or 
> media-hub is playing in the background.

Similar to the current design: <https://wiki.ubuntu.com/Sound#role>
|
| * Otherwise, if media is playing, the active output role should be
| "multimedia".
| * Otherwise, the active role should be "alert".

("Alert" here includes ringtones. If you're playing music and your
phone rings, you should still be able to adjust the ringtone volume,
because the music should have paused automatically.)

> * Make the volume slider in the indicator always control the 
> multimedia volume, never touch the ringtone volume.

Besides the same problem of quieting a ringing phone, this is also
funny because Michał Sawicz proposed the exact opposite: "Sound
indicator should only indicate ringtone volume"
<http://launchpad.net/bugs/1478075>. (Though he never explained why.)

> * Apps should always use the multimedia role, regardless of what 
> they do (unless thy deal with actual calls or incoming messages).

So should VoIP apps -- Skype, Google Hangouts, Facebook Messenger, etc
- -- use the same "actual calls" volume level for their calls? It would
be odd if they didn't. But if they should, that's a third role.

> * Add a second "slider" to the indicators that controls ringtone 
> volume. That slider could be a bit special tho, i.e. that it works 
> more like a profile selector. 0 is "vibrate only", 1 is "beep" and 
> all the greater values adjust volume of the ringtones.

Making Silent Mode part of the volume slider is an interesting idea
(and Android and Windows Phone do this already), but that does not
require changing the roles or adding extra sliders.

Apparently "beep" is an old Nokia feature, but I'm not confident that
people would understand what it was for if it was part of a volume
slider.

> One thing I've not mentioned here yet are alarms. Alarms, again 
> could/should have their own role.

Well then, now we're up to four roles ... the same as the current
design!

So, yes, the current four roles are complex. And maybe they need
tweaking. But it's unlikely that they're *unnecessarily* complex.

> But one never controls that role with either the buttons or a 
> slider. Instead, each alarm has his own volume value assigned when 
> the alarm is created, and an alarm is always played at the volume 
> its config says (except maybe only vibrate when the phone profile 
> is set to vibrate only - but those are small details we could work 
> out on the road).
> 
> ...

That would have two drawbacks. First, it would make the UI more
complex for every app that sets alarms -- even in just the
default/impending-default apps, we'd need volume sliders in Clock,
Calendar, Tasks, and Notes. Yikes.

Second, it implies that "The volume I specified for the alarm, however
long ago I did that" is more likely to be appropriate *now* than "the
volume I adjusted, or was okay with, the last time an alarm went off".
I think the reverse is true.

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlYBg5MACgkQ6PUxNfU6ecowWQCeJvRGJsCbS1GtAYxnVeJnM9Xo
F6UAnj/4xsHgwseDDXtqcMrTqbn3DQ57
=YEX/
-----END PGP SIGNATURE-----