ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

Hi,

Matthew, thanks for th detailed reply.

On 22.09.2015 18:36, Matthew Paul Thomas wrote:
> 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%.

Well, this is not really a bug in an implementation itself, but rather
in the way we use the buttons. I press volume down a couple of times
wanting to adjust the game value, but instead it acts on the ringtone
volume because the game currently doesn't play a sound. The short sound
effects are too short to make the buttons act on them in a useful way.

> 
>> 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>

Hmm, I think this is a good point where we have a different
understanding: You say in silent mode some things should be silenced
(ringtones, background music, sound effects) but some things should
still be playing (manually-played videos).
I for one would assume that when I put silent mode on my phone, it is
silent. Even manually played videos shouldn't make a sound unless I
explicitly raise the multimedia volume which would exit silent mode.
Note that I'm not necessarily saying this would also raise ringtone
volumes. Ringtone volumes might still be at 0, but it's not in "silent
mode" any more. When the phone says it is in silent mode, I rely on the
fact that I can do whatever I want with it and it won't make a sound.

I guess alarms would be a special case indeed here which might escape
the silent mode and still are allowed to make sounds there. Not sure...
I guess alarms from the clock application are different than calendar
entries there. I would want my phone to wake me up in the morning even
though I left it in silent mode yesterday, however, in silent mode I
don't want my phone to ring a calendar entry every hour. Maybe calendar
entries should use the multimedia or ringtone role too and only real
alarms from the clock app have the special alarm casing...

I agree that relying on the app developer to take care about it is not
way to go here.

> 
>> 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:

Yes. As I replied to Alan in another mail of this thread, I agree, I've
missed that at first.

> 
>> 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.)

I think the main difference here is "if media is playing" vs "if an app
with audio permission is focused". An app (for example Dinosaur) might
not be playing any background music, just very short sound effects.
Those sounds are too short for the user to react on them and press the
volume buttons. By the time the buttons are pressed, we're back in the
alert role and the user controls the ringtone instead of those sound
effects.

> 
>> * 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.)

If we continue to only have one slider, yes, it should probably be the
ringtone one. But I would really suggest to add multiple sliders. One
for each role except the one for alarms.

> 
>> * 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.

Why is that a third role? IMO just the same as the primary ringtone 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!

Not really, so far there's two, and the alarm, which I probably wouldn't
treat like the other two roles. Meaning, an alarm doesn't need to be
adjusted like the others, by pressing the hardware buttons or having a
slider for them, the volume for them is defined when the alarm is set
up. So yes, it could be a "role" in that sense, but more hidden than the
other two.

> 
> 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.

IMO that would be quite nice tbh...

> 
> 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.

I think of it rather this way: The alarm that wakes me up in the morning
should always be the same volume, regardless of the volume that reminds
me of meetings during the day. I would want to have alarms for calendar
entries rather silent to not disturb the whole office all day long, but
the morning alarm needs to be full force ahead, or I'll sleep in. And I
can't manage to remind myself every evening to check and adjust the
alarm volume for the next morning.

Br,
Michael

Attachment: signature.asc
Description: OpenPGP digital signature