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
