Hi folks, As we know, there are a bunch of 1.3 bugs on audio competing we couldn't fix. To fix them and pass the certification, we have put many effort on the apps with audio, like music, video, clock and ringtones. Take music as an example, we even implemented an uncommitted feature to fix bug 946556, and landed an ugly workaround in bug 956811, not to mention the other apps.
Actually the audio channel management in gecko[1] has done a great job on handling the audio competing issues, but due to the complexity of ui and various usages of the audio element(or web audio), it seems that we need to enhance the management, or we are unable to fix the unsolved bugs and satisfy the feature requests in the future, like the various devices and screen sizes we are facing of, such as TV and tablet which might have different ui and different audio managements. To catch the attention, there was a mail thread[2] called "Improve audio competing policy and user experience" before the CNY, and thanks to the responses of ux team and devs, we had a couple of ux/technical discussions[3], to understand how gecko manage the audio channels currently, also went though the existing audio competing bugs[4]. The result was, we found because gecko does not know how ui behaves and only interrupt/resume by judging which channel type the app/iframe is using, with the app/iframe's visibility, some of the scenarios are not considered and could not be handled well. So due to all the reasons I have mentioned above, we decided to move the audio competing management from gecko to gaia, so that bugs can be fixed and apps do not need the workarounds, and for different branches like TV and tablet, imagine that we can customise the audio competing management to adapt different ui in gaia without branching geckos. Of course, to achieve this goal we will need new web api, or a browser api that can pause/resume the audio elements in the iframe, then a sub-module of system app is capable of managing the audio channels by calling the browser api of each iframe, there is a pending bug(Bug 853101) that implemented this browser api, we should continue on it since it's already r+, or recap it to fit our requirements. So now we have action items for UX, Gaia and Gecko, and thanks to everyone we are in good progress: - UX team: Harly and Omega are working on the guideline of the audio competing policy. - Gaia devs: Dominic and Alive will work on the audio channel management(bug 961967). - Gecko devs: Star and Marco? will help on the browser api(bug 853101). We hope the gaia audio channel management can be enabled in 1.5 or later, and the workarounds can be removed and gives better user experiences to our users. Please let us know if you have any questions, or you are interesting in implementing it! [1] WebAPI/AudioChannels: https://wiki.mozilla.org/WebAPI/AudioChannels [2] Email Thread: https://groups.google.com/forum/#!topic/mozilla.dev.gaia/9HtUGlgBwC8 [3] Etherpad: https://taiwan.etherpad.mozilla.org/566 [4] [AUDIO_COMPETING]: http://goo.gl/gx3rri Thanks, -Dominic _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
