Hi all, To re-post the idea on creating new Web API for Audio Routing on mobile device from dev-b2g mail list since there are no much responses. And the content as below is the original mail content from Randy Lin.
----------------------------------------------------------------------------------------------------------------- Hi All, Recently, we have several implementation which related to the audio routing. 1. Feature request: [Bug 854753] [FMRadio][User Story] Implement the FM Radio SpeakerOn function 2. add ConnectSco(), DisconnectSco() DOM API on bluetooth , landed:https://bugzilla.mozilla.org/show_bug.cgi?id=830213 3. telephony has speakerEnabled API for forcing voice sound from receiver to speaker 4. headphone switch event on AudioChannelManager For the design of cellphone, the audio routing should be considered in system level. Q: Is it possible for b2g to have a routing manager which be responsible to manage the device's routing stuff, such as 1. Provide audio path switch API 2. Broadcast routing change event. 3. Handle the application switch case, i.e one application want speaker on with headphone pluged-in, switch to another one, but there is no option for users to switch back to headphone. this object may need to tracking the application usage and recover it. Randy ----- Original Message ----- From: "Randy Lin" <r...@mozilla.com> To: "Alive Kuo" <al...@mozilla.com> Cc: dev-b2g@lists.mozilla.org Sent: 2013年5月13日 星期一 18:28:06 Subject: Re: [b2g] [B2G] Audio path routing For the API level, we may have an API like this setSpeakerOn(bool en) and isSpeakerOn The application switch case may be complicated because...with headphone pluged-in case and playback on speaker: 1. app A use content channel and playing on speaker, another app B use normal, should output on speaker or headphone? I prefer speaker. 2. app A use content/normal and playing on speaker, another app B use higher channel than before, like dialer, which output path do we want to have? receiver? speaker? *headphone? After ended the app B with higher channel, the audio sound can back output on speaker. ============== 3. Handle the application switch case, i.e one application want speaker on with headphone pluged-in, switch to another one, but there is no option for users to switch back to headphone. this object may need to tracking the application usage and recover it. If you have a speakerOn function I assume that you will also have a speakerOff function. Then in those app who wants to control the state of speaker, they should listen to 'visibilitychange' event to know the foreground/background state change(application switch you mean), and then according to that, enable or disable speaker. The only thing I wonder: there may exist one race condition, if App A is brought to background after App B is brought to foreground. When that happens, the speaker(I guess it's global?) will be disabled by App A when it gets notified it's now background after App A enables it. _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
