ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

Hi

On 29.09.2015 20:54, Matthew Paul Thomas wrote:
> Michael Zanetti wrote on 24/09/15 10:04:
> 
>> ...
> 
>> 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.
> 
> Okay, so that is the bug with the default role not being the one that
> sound effects use. <http://launchpad.net/bugs/1498466>

No. The issue is that the sound effect is playing too short and thus the
hardware buttons have not enough time to work on that role.

Yes, you could workaround this by making the SoundEffect use the same
role as the ringtone, but that would introduce new issues:

a) I cannot have the sound effects in games muted but still hear my
ringtone.

b) If a game has sound effects and background music, the issue would be
back. As the background music's role (multimedia) would be active most
of the time and the SoundEffect/Ringtone role comes active for fractions
of seconds only, not allowing to adjust them reasonably.

The only way to fix this issue by changing the sound effects role, is to
change/drop *all* of the roles, otherwise there will always be
combinations of roles which will bring this issue back. I agree we don't
want to drop all the roles, hence my proposal to keep the current role
(multimedia) active for the full time while an app with audio permission
is focused, not just while something is actually playing.
Also all sounds an app creates should end up in the multimedia role.

> 
>> ...
>>>
>>> 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.
> 
> In the past week, nobody noticed that that code produced the exact
> opposite result of what I intended ... which is not a good sign for
> developer adoption either.
> 
>>> <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.
> 
> I don't think it's reasonable to prevent people from silencing their
> ringtone and notifications when watching a video with sound. On the
> contrary, watching a film is precisely one of the situations where I'd
> want to do that.

I never said that... I just said that if I activate silent mode,
everything should be silent. But I would still allow to move the
ringtone slider to 0 and keeping the multimedia slider at 100.

IMO the "silent" mode is the one that is activated when going into a
meeting, or in class in school/university. You activate the silent mode
and rely on the fact that the device doesn't make a single beep so the
teacher doesn't take it away or you don't disturb the meeting/lecture,
even if you are playing around with the device because you're bored by
the lecture/meeting. If our silent mode still allows producing sounds
it's basically useless as a silent mode as one never can rely on it.
Each tap in the UI could potentially start playback of something...

> 
> (Maybe one day we'll have a Do Not Disturb or similar mode that will
> fulfil that use case even better. But the existence of a Do Not
> Disturb mode would not change the effect that I'd expect Silent Mode
> to have.)

Right... it could be called DND mode... but it's really the thing... Not
sure what a silent mode would be good for if it doesn't silence
everything (again, with the exception of alarms perhaps)...

> 
>> 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...
> 
> Yes, whether calendar notifications should differ with Silent Mode is
> a murkier question than whether clock alarms should. The current
> designer has said that Silent Mode should mute calendar alarms.
> <http://launchpad.net/bugs/1440111>
> 
> But that's a question that would be made harder, not easier, by moving
> it from the app's control to that of the OS. The OS has much less
> information to work with.

Yes, I'd keep it in the app's control for the alarm case... The clock
app having a slider for the clock alarms, the calendar app having a
slider for the calendar alarms volume and so on...

> 
>> I agree that relying on the app developer to take care about it is 
>> not way to go here.
> 
> I disagree. When I said "It requires care from app developers", I
> meant "It *has to* require care from app developers" -- because
> without app instruction, there's no way that an OS can tell how
> important a particular sound is.
> 
> So it's the SDK's job to make it as easy as possible (and/or
> compulsory) for app developers to make that decision. That's where the
> SDK is failing.

No... IMO the app developer shouldn't have to do anything.. Every sound
an app makes should be part of the multimedia role and the OS
controlling the volume. Otherwise we'll keep staying in the mess that
every app behaves different and everything is totally unpredictable.

The only exception is when apps produce ringtones for messages/calls,
but in those cases apps would not use Auido {} or SoundEffect {}, but
instead the push-helper plays the ringtone sound. In other words, only
trusted helpers for calls, messages and alarms should be allowed to
produce ringtone/alarm sounds. Everything else the app creates is
multimedia.

> 
>> ...
>>>
>>>> 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".
> 
> What do you mean by "audio permission"? As far as I know, apps don't
> need any permission to play audio. (Or if they do, they all have that
> permission by default.)

They do require a permission, and they don't have it by default.

> 
>> 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.
> 
> Right, that's the same role bug as above.
> 
>> ...
>>>
>>>> * 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.
> 
> So you'd have the same role for ringtones and calls? That could be
> pretty annoying. For example, I used to work on a fruit grading line
> where the office phone ringer was really loud. It had to be, because
> otherwise no-one would hear it over the noise of the grading machine.
> Did that mean the calls themselves should have been just as loud? No,
> because whenever someone answered the phone, they did it after going
> into the office and closing the door. If that had been a mobile phone,
> having to turn down the volume every time we answered a call -- and
> remember to turn it up again every time we finished -- would have
> gotten boring fast.

Oh, now I get it... the calls role is the volume of the actual call
voice... Right, I didn't regard that before either... Fair enough, we do
have an additional role there, although I'm not sure if that role should
ever be exposed to 3rd party apps in any way. I would probably consider
it an internal state of the dialer/telephony app.

> 
> I actually think it's more plausible that we'd combine the roles for
> calls and multimedia, than for calls and ringtones. After all, most
> calls are through the earpiece, while most multimedia is through
> speakers or a headset. And, per spec, "sound volume should be
> remembered independently for each *combination* of primary output
> device and active output role". So you could set, once, different
> preferred volumes for (a) music through speakers, (b) music/calls
> through headset, and (c) calls through the earpiece, despite them all
> sharing the same role, and seldom have to touch them again. Obviously
> (b) would be the main risk of contention.

Hmm... that doesn't sound good to me. For instance, I want multimedia
sound to be silenced most of the time, but that doesn't mean I don't
want to hear the other person talking on phone calls. I see your point
about the audio output device separting them, but still, would break as
soon as you plug headphones.

> 
>> ...
>>>
>>> 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.
> 
> That introduces a third drawback, besides the two I described already:
> if an alarm went off in your pocket, you might reasonably guess that
> reaching in and mashing the volume down button would quieten it until
> you could remove it from your pocket and take more decisive measures.
> But no such luck! The alarm would ignore the volume buttons
> completely, merrily disrupting your exam or audition or seance or
> whatever.

Well, I don't think you want to fiddle with volume in that case... each
alarm will paint a notification with stop/snooze buttons. You really
want to hit those instead of pressing the volume button like 20 times
and then sleeping in the next morning because after the exam you
certainly won't remember to increase the volume again. And even if you'd
remember to restore the volume, you'd need to wait for the next alarm to
silently ring, because otherwise you wouldn't have any way to adjust
volume again if we keep the current model of the buttons/slider only
working on a currently playing role.

> 
> (We might make the power button snooze/stop alarms, but that wouldn't
> affect the volume buttons.)

I like the idea of snoozing/stopping alarms with the power button.

> 
>> ...
> 
>>>> 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...
> 
> Well, this poses a quandary. Can you think of any evidence that would
> persuade you that this is a terrible idea? :-)

Not really... It's not that every app sets alarms. Its the clock app and
the calendar app. There might be some more examples but it's gonna be a
hand full at max.

> 
> (For me, screenshots of any existing first-party app with individual
> volume controls for individual alarms would suggest that maybe it's
> not as terrible as I think.)
> 

http://i.imgur.com/RPh37qv.png

Doesn't this scream for a volume slider to have a predictable volume for
the alarm I'm just setting up? :)

Right now I just can't make any prediction of how loud the alarm will
ring... It might be full volume, but it might just be silenced, I can't
know.

>>>
>>> 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.
> 
>> ...
> 
> I understand the niceness of having different volumes for alarms in
> different environments. But that way of achieving it wouldn't help as
> many people as you seem to think. Some proportion of people wouldn't
> notice the sliders in the first place. Of those who did, most wouldn't
> understand why they were there. And of those who did, only a small
> fraction would be like you and put enough thought into it to decide,
> "hmmm, loud alarm in the morning, quiet alarms during the day".
> 
> Meanwhile, *everyone* would have the problem of "Argh, the last alarm
> I set was too loud, and so is this one, and so will be the next one,
> and the volume buttons don't even do anything" -- whether they knew
> about the sliders or not. And even if they did know, fixing the
> problem would require changing multiple sliders for however many
> alarms they had. You have to take medication four times a day, and the
> first alarm was too loud? Well then, taking the medication is not even
> the most boring thing you'll be doing today. You'll also be twiddling
> four sliders in four separate dialogs! Woohoo!

It's not that bad, really... If the alarm in the morning wasn't adjusted
as you wanted. You go to the clock app and adjust it, once, maybe a
second time. If the calendar reminders are not what you want, you once
go to the calendar and adjust it. That's it. You don't have to do that
every day. You'll figure the volume that matches your day pretty quickly.

If instead all alarms are the same volume, and every time I change one I
change all of them, then indeed, I will spend most of the day adjusting
the upcoming alarms, or actually, as I do now, not trust the device that
it will ring with a sound level which I will hear and rather use
something else to remind me of things.

When it comes to alarm its about reliability. I rather tweak the volume
twice in the clock app and then two more times in the calendar app than
not being able to rely on it ringing.

> 
> A much simpler solution would be to have alarm sounds that start out
> quiet, and -- over a period of twenty seconds or so -- gradually get
> louder. That would work no matter what environment you're in.

I like that idea too. I don't think it is the solution to the problem,
but a nice addition, and probably should be optional.

Br,
Michael

Attachment: signature.asc
Description: OpenPGP digital signature