ubuntu-phone team mailing list archive

[Jim Hodapp <jim.hodapp@xxxxxxxxxxxxx>]

mpt,

In discussing this more with Michael, one of the real issues seems to be
the following:

When an application is focussed, the audio role for the volume output
should be multimedia and no longer the phone role. This isn't true at the
moment. When an app like one of Michael's games plays a sound with the QML
Audio element, it gets played with the multimedia audio role, but then the
volume role for what the indicator-sound is currently controlling switches
back to the phone role. indicator-sound is always reporting what the
default pulseaudio output sink volume role/level currently is (that's my
understanding of it at least). Only once the app is no longer focussed and
the focus goes back to the dash, should the audio role return to the phone
role. This gets a little more complex in implementation because some of the
scopes can also play audio and would do so through the multimedia role, but
that's a separate issue in my opinion.

Thoughts?

Jim

On Tue, Sep 22, 2015 at 12:36 PM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>
wrote:

> -----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-----
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>