1019294 - [B2G][Audio] Changing the volume while previewing a ringtone doesn't make it any louder/quieter

Status: RESOLVED DUPLICATE of bug 993293

(Firefox OS Graveyard :: AudioChannel, defect)

Description

[Josh Schmitt [Joshs]]

Attachment: log.txt

Description:
Changing the sound volume in Manage Ringtones will set every audio to that sound setting and user is unable to hear audio changes

Repro Steps:
1) Update a Flame to 20140530000202
2) Open Settings > Sound > Manage Ringtones
3) Play a few ringtones while changing the volume of the device
4) Close the Settings app
5) Launch the Music app
6) Play a song and change the volume of the music


Actual:
The volume does not change.

Expected:
The volume changes.

Environmental Variables:
Device: Flame
Build ID: 20140530000202
Gaia: fe612fd21389193a8e593aa718831602e5086a62
Gecko: 25011f9a8f26
Version: 30.0 (1.4) 
Firmware Version: v10G-2

User agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Notes:
Repro frequency: 100%
See attached: logcat

Comment 1

[Josh Schmitt [Joshs]]

Unable to test on 2.0 Buri due to bug 1018406 Will retest on buri when issue is fixed.

Issue does NOT repro on 1.4 Flame as there is no Manage Ringtone option in settings.

Issue does NOT repro on 1.4 Flame.

1.4 Environmental Variables:
Device: Flame
Build ID: 20140530000202
Gaia: fe612fd21389193a8e593aa718831602e5086a62
Gecko: 25011f9a8f26
Version: 30.0 (1.4) 
Firmware Version: v10G-2

Comment 2

[Jason Smith [:jsmith]]

This isn't a regression - this is a new feature in 2.0 being used to reproduce the bug.

The STR here isn't clear as well - specifically step #3. Step 3 needs to be spelled out more clearly on what steps were used to reproduce the issue in the least amount of steps that are needed to reproduce the bug.

Comment 3

[mhall]

Repro Steps:
1) Update a Flame to 20140609040203
2) Open Settings > Sound > Manage Ringtones
3) Select/Play any ringtone while tapping the volume button up or down on the device
4) Observe that tapping the volume button will have no affect on the audio volume of the device.

Note: The above STR will produce the same results on the Buri 2.0

Environmental Variables:
Device: Flame 2.0
Build ID: 20140609040203
Gaia: 12af93123c5db55212d51fe235d39f21209a1eaa
Gecko: 9305a8ec77fe
Version: 32.0a1 (2.0) 
Firmware Version: v10G-2

Device: Buri 2.0
Build ID: 20140609040203
Gaia: 12af93123c5db55212d51fe235d39f21209a1eaa
Gecko: 9305a8ec77fe
Version: 32.0a1 (2.0) MOZ
Firmware Version: v1.2device.cfg

Comment 4

[Tony Chung [:tchung]]

broken new feature bug

Comment 5

[Dominic Kuo [:dkuo]]

I think the root cause should the same as bug 1020771.

Comment 6

[Andreas Gal :gal]

bug 1020771 is untriaged, and nobody is working on it. This bug hasn't moved in 11 days. What's going on here?

Comment 7

[Tony Chung [:tchung]]

:

    i nom'd bug 1020771.  if that really is the blocking bug for this one, then lets get that one 2.0+'d and assigned.

Comment 8

[Jim Porter (:squib)]

tl;dr: bug 1020771 can mask the problem in this bug, but doesn't *actually* fix it (it just reduces the problem).

Actually, you can't even change the audio of the ringtone you're previewing either, so I don't think this is exactly an issue in the ringtones app (except that we're triggering the bug, of course). In other words:

1) Open ringtones app (manager or picker)
2) Preview a ringtone
3) Try to change the volume
4) The ringtone doesn't get quieter or louder

At the risk of stating the obvious, the volume control should control the volume of whatever is currently playing, no matter what that is or what audio channel it's using. Now, the ringtones app keeps a WebAudio context open (with the channel set to "ringer") from when you start previewing a ringtone until you close the app, but if it's in the background, you can still play music and the sound comes out just fine. However, the volume control doesn't work, even though it's playing music. Maybe the volume control thinks we're mixing the audio channels together, which doesn't really make sense since the ringtone app stops making noise when it's in the background (I don't actually know why it does this).

Further, if you have the ringtone app open and have previewed a ringtone, then Music will stop playing once it leaves the foreground too. That part is probably a bug in the ringtones app (sort of), and I imagine it would have the knock-on effect of fixing comment 0. But it wouldn't fix the issue where you can't change the volume of the ringtone you're in the middle of previewing.

The moral of the story here is: Do Not Use Audio Channels. They are a fundamentally broken model for determining what audio to play when.

I'm not actually sure what the solution here is. I guess I can just make bug 958470 comment 3 all the more accurate by adding yet another workaround for the nightmare hellscape that Audio Channels have become, but I'd really rather rip all that code out. I'm not convinced that the problem we're solving (forcing background audio to stop when we preview a ringtone) is worth the potential for bugs.

Comment 9

[Andrea Marchesini [:baku]]

> The moral of the story here is: Do Not Use Audio Channels. They are a
> fundamentally broken model for determining what audio to play when.

I see several problems here:

1. Why the settings app is using 'ringer' audioChannel when the user selected the ringtone?
Probably it should use 'content'. The ringtone is not actually used as ringer in this case.

2. The default audioChannel volume is selected by the app. It seems that the Settings app is using the wrong audioChannel for the volume.

3. I agree that the AudioChannel policy is over complicated and probably we should try to simplify it, but I don't think any audio policy is actually the root cause of this bug.

To me the main problem is that the volume controller is often changing the volume of the wrong channel.
I suggested months ago to have the volume controller as the master volume for any audioChannel. This was probably too simple and it didn't match the UX requirements, but what we have now is really unclear to me.

I'm not really familiar with the AudioChannelManager (that is in charge to changing the volume for the audioChannel, right?). So I NI mchen.

Comment 10

[Jim Porter (:squib)]

I landed bug 1020771 which fixed the originally-reported issue, but there's still stuff left. From comment 8:

1) Open ringtones app (manager or picker)
2) Preview a ringtone
3) Try to change the volume
4) The ringtone doesn't get quieter or louder

Since this is a bit different now, I've re-flagged it for blocking-b2g:2.0. I'll leave it to others to decide if this should still be blocking.

Comment 11

[Jason Smith [:jsmith]]

Using the STR indicated in comment 10, can we check if this happens on 1.4 again?

Comment 12

[Dominic Kuo [:dkuo]]

(In reply to Andrea Marchesini (:baku) from comment #9)
> > The moral of the story here is: Do Not Use Audio Channels. They are a
> > fundamentally broken model for determining what audio to play when.
> 
> I see several problems here:
> 
> 1. Why the settings app is using 'ringer' audioChannel when the user
> selected the ringtone?
> Probably it should use 'content'. The ringtone is not actually used as
> ringer in this case.

The reason we use 'ringer' audio channel in settings app is because we want to let the user hear the real volume when they are previewing the ringtone in the sounds panel, we also do that for the 'alarm' channel to get the right volume. But if we want to use the 'content' channel to preview the tones with right volume, we might need to change the volume of content channel every time when previewing different tones, to pretend the content channel has the other channel's volume.

> 2. The default audioChannel volume is selected by the app. It seems that the
> Settings app is using the wrong audioChannel for the volume.

UX has a sound ux spec in bug 991026(attachment 8420872 [details]) and we have landed it for 2.0, so the default volume we control now in Settings app is the ringer & notifications volume.

> 3. I agree that the AudioChannel policy is over complicated and probably we
> should try to simplify it, but I don't think any audio policy is actually
> the root cause of this bug.

Agreed.

> To me the main problem is that the volume controller is often changing the
> volume of the wrong channel.
> I suggested months ago to have the volume controller as the master volume
> for any audioChannel. This was probably too simple and it didn't match the
> UX requirements, but what we have now is really unclear to me.

Omega has provided us a sound ux update spec in bug 991026, and hope it can help you to understand what we have recently fixed for 2.0.

Comment 13

[Preeti Raghunath(:Preeti)]

Lived with the same issue in previous releases

Comment 14

[Andrew Overholt [:overholt]]

If this bug has become only what Jim describes in comment 10 then I think it's a dupe of bug 993293.