868901 - [B2G][Audio] implement mozAudioRoutingManager

Status: RESOLVED DUPLICATE of bug 863098

(Firefox OS Graveyard :: General, defect, P3)

Description

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Attachment: IDL draft

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 1

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

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.

Comment 2

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

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

Comment 3

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

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();

Comment 4

[Justin Lebar (not reading bugmail)]

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.

Comment 5

[Marco Chen [:mchen]]

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.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 7

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

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

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 745745 [details]
IDL draft

removing this request since the work is now being done elsewhere