The team has been working in this. I'll ask Mike to follow up after CNY when we are together next week.
We can also review with product team. Thx for patience. Sent from my iPhone > On Jan 30, 2014, at 7:51 PM, Hema Koka <[email protected]> wrote: > > Jaime, > > Any update on this? > > For 1.3, we have come across a bunch of bugs on audio competing policy > decisions and the user experience around it affecting some of our core apps. > It would be wonderful if we can get ux recommendation around various cases > and get this into our roadmap. > > Thanks > Hema > >> <compose-unknown-contact.jpg> Jaime Chen January 9, 2014 11:35 AM >> Hi Marco- >> Let me have the team take a look and we'll follow up. Thanks for calling >> this out. >> >> Cheers! >> Jaime >> >> ---- >> Jaime Chen >> UX Manager & Design Strategist >> Firefox OS, Mozilla >> >> >> >> >> >> >> <compose-unknown-contact.jpg> Marco Chen January 9, 2014 12:36 AM >> 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 >> >> <postbox-contact.jpg> Dominic Kuo December 19, 2013 6:22 PM >> 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 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
