Hi Dominic, This is a great article and I know we still have something to do with audio channels but haven't began.
I'd like to see this happens: Move audio competing management from Gecko to Gaia::System, with mozBrowser API. https://wiki.mozilla.org/WebAPI/AudioChannels#System_and_Browser_API_changes I'm confident we could have a better audio management from Gaia::System than Gecko, for the sake system knows the state of apps well. @Baku, I know you own that bug but if you don't mind I would love to seek resource from Taipei platform team members to make sure this could happen in v1.4. -Alive Dominic Kuo <[email protected]> 於 2013/12/20 上午10:22 寫道： > 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 competing 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 hope 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 > -- Alive C. Kuo, Front-end Engineer, FirefoxOS, MoCo. Taiwan, Taipei office. [email protected] _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
