For Firefox OS, It seems we should have a routing control object that allows webapps can 1. force audio path routing to speaker bug: 854753, [FMRadio][User Story] Implement the FM Radio SpeakerOn function , User case: Bug 863098 - [UX Spec] User should be able to switch to speaker out while listening to FM Radio using ear plugs. 2. allow webapps can force routing to bluetooch sco use case: telephony, voice recognized 3. let other module can query audio path status Bug 868348 - [System] Headset module 4. keep the routing information in b2g, need to solve this bug: Bug 867078 - [B2G][Audio] Audio path/volume control can't work when media server crashed. 5. This object should have permission to use, IMHO, we should let the audio path control in a single object and let all apps use this API instead of hacking way.

Comment on attachment 745745 [details] IDL draft Hi Jonas, Can you help to feedback this, I think separate the B2G audio routing form the audiochannelmanager may let the API to be clear and easy to use.

This object should handle the media Server crash issue and recover the routing informtion, may implement in client/server DOM object.

related bug: [Bluetooth][Certification]HFP PTS TC_AG_ATH_BV_04_I failed due to there is no API for disconnect SCO connection they add three api on // Connect/Disconnect SCO (audio) connection nsIDOMDOMRequest connectSco(); nsIDOMDOMRequest disconnectSco(); nsIDOMDOMRequest isScoConnected();

I haven't been following the discussion in bug 854753, but it seems relevant here, so I'm going to untag my f?; Jonas seems on top of this.

Hi Jonas, May we know is it a suitable plan for collecting all audio routing APIs into one centralized category? Very thanks for your suggestion.

If my proposal in bug 863098 comment 28 is accepted by everyone, then I think we need something like: interface SpeakerManager : EventTarget { attribute boolean forceSpeaker; attribute EventHandler onforcespeakerchange; attribute boolean speakerButtonEnabled; }; So the application would when it renders a speaker button set speakerButtonEnabled=true, and then read the forceSpeaker property to know which state to render the button in.

Hi Jonas, It make sense to have speaker control api first. I will keep tracking on this bug 863098.

Comment on attachment 745745 [details] IDL draft removing this request since the work is now being done elsewhere