Hi all,
It seems that this thread didn't attract much attention so I tried put more
issues which is waited to be fixed.
Bug 911238 - [AudioChannel] Consider to let normal channel play in the
background.
Or listen music from
third party web site will not be allowed to perform in the background.
Bug 871467 - [AudioChannel] To generate alert tone during in_call state when
alarm/notification is fired.
Or during phone call
user doesn't have chance to notice any alart or notification coming.
Bug 918626 - [Fugu][Buri][Camera][Music]When taking pictures,music intermittent
Or user can't hear
shutter sound because music volume is too big.
Bug 946556 - Music app in foreground can play the music now but components
underlying Gecko will block music stream during phone call.
The section of audio competing policy in [1] give the brief introduction of
what we have now.
And actually we didn't have any UX spec to show our audio competing policy, we
only collect each UX's reply in each bugs then implement it in each patches.
So every time someone argue about this, we need to find out the decision made
by which bug then show to him/her.
[1] https://wiki.mozilla.org/WebAPI/AudioChannels
Thanks,
Sincerely yours.
----- 原始郵件 -----
寄件者: "Dominic Kuo" <[email protected]>
收件者: [email protected], [email protected],
[email protected]
副本: "Rob MacDonald" <[email protected]>, "Christopher Lam"
<[email protected]>, "Jacqueline Savory" <[email protected]>, "Casey (Kok
Ching) Yee" <[email protected]>, "Marco Chen" <[email protected]>, "Andrea
Marchesini" <[email protected]>, "Alive Kuo" <[email protected]>, "Hema
Koka" <[email protected]>
寄件備份: 2013 12 月 20 星期五 上午 10:22:14
主旨: Improve audio competing policy and user experience
Hi folks,
Recently Gaia has encountered some audio issues that the current audio channel
API [1] did not
consider of, such as pick an audio file then preview it in mms while music is
playing in the
background(bug 894744), or talking in a call and listen to the music at the
same time via bluetooth
headset(bug 946556). These scenarios are not so common but let us know there
are spaces we can
improve for our audio channel policy/API, so I am sending this email to start a
thread.
From the perspective of audio channel API, the behaviours in the above bugs are
expected, but it
confuses our users and probably also mess up the ux that we are trying to keep
in the firefox os. I
have discussed with Marco and Casey about how we can solve this gap, and we
thought it might be
a good idea to start a discussion between devs and ux team to make sure we are
on the same page.
As an author of the music app, I believe the original audio c ompeting policy
was intended not to let
the apps involve the competing too much, and the apps can focus on the features
and don't have to
write some extra logic. But due to new features are making new issues, we can
probably provide
more api or information for the apps to handle the competing. This depends on
how our ui looks/feels
like and what ux we want to give to our users, so it might be better that ux
team can provide the policy
or rules from ux perspective, especially for the existing bugs [2][3] to help
the devs to design/implement
the new API if needed.
And since there are several audio competing bugs are first filed in
Gaia::Music, this inspired me to
do some investigations on the audio competing issues on the mainstream mobile
OSes. I just picked
two simple scenarios to test and the results are listed in the table below.
Scenario 1 : The user answered a call and tried to bring the music app to the
foreground then play music.
Scenario 2 : The user is listening to the music, then go the settings to change
the ringtone.
OS
Scenario 1 Scenario 2
Android
1. The music will pause during the call.
2. The play controls in the music app will be disabled.
3. If the user try to resume the music, a prompt will come out and let the user
know it's disabled because of some reasons.
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music still plays in the background.
2. The previewing ringtone and music will be mixed together.
iOS
1. The music will pause during the call.
2. We can still play the music during a call.
3. Music will be mute.(playing without sound)
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music will pause.
2. When the user brings the music to the foreground, then music will resume
automatically.
Windows Phone
1. The music will pause during the call.
2. We can still play the music during a call.
3. Music will be mute.(playing without sound)
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music will pause.
2. When the user brings the music to the foreground, then music player is in
pause state.
Firefox OS
1. The music will pause during the call.
2. We can still play the music during a call.
3. The voice and music will be mixed together.
4. After the call ends, the music will resume automatically.
1. When previewing the ringtone, music still plays in the background.
2. The previewing ringtone and music will be mixed together.
From the table I think every OS has it's own principle to handle the audio
competing, though I cannot
tell the exact idea, but basically we can see some OSes allow the sounds to be
mixed but some prefer
not to do so. I h ope this is a good start and can give ux team some ideas to
design the audio policy for
the bugs or the features in the future. And if ux team can drive this and pilot
the devs, that will be great!
Any thoughts?
[1] https://wiki.mozilla.org/WebAPI/AudioChannels
[2] Audio Channel: http://goo.gl/kLhP95
[3] [AUDIO_COMPETING]: http://goo.gl/rTvxag
Thanks,
- Dominic
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
