WebAPI/AudioChannels: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 11: Line 11:


The channels are:
The channels are:
* normal: UI sounds, web content, music, radio
* ''normal'': UI sounds, web content, music, radio
* notifications: New email, incoming SMS
* ''notification'': New email, incoming SMS
* alarm: alarm clock, calendar alarms
* ''alarm'': alarm clock, calendar alarms
* telephony: phone calls, voip calls
* ''telephony'': phone calls, voip calls
* publicnotification: forced camera shutter sounds
* ''publicnotification'': forced camera shutter sounds


We'll have separate mute and volume settings per channel. We'll additionally have a volume and mute setting for a "headphones" channel.
We'll have separate mute and volume settings per channel. We'll additionally have a volume and mute setting for a "headphones" channel.
Line 23: Line 23:
For now all audio channels except "telephony" never use the built-in earpiece. I.e. they always use the speaker or headphones/headset. We might introduce using the built-in earpiece for "normal" sounds in a future version.
For now all audio channels except "telephony" never use the built-in earpiece. I.e. they always use the speaker or headphones/headset. We might introduce using the built-in earpiece for "normal" sounds in a future version.


== API ==
== Application API ==


  interface AudioChannelManager : EventTarget {
  interface AudioChannelManager : EventTarget {
   muteChannelsBelow(DOMString type);
   muteBelow(DOMString type);
   unmuteChannels();
   unmuteAll();
   readonly attribute DOMString[] mutedChannels;
   readonly attribute DOMString[] mutedChannels;
   attribute EventHandler onmutedchange;
   attribute EventHandler onmutedchange;
Line 43: Line 43:
  }
  }


When muteChannelsBelow is called, it changes the mutedChannels property of all AudioChannelManager instances in all apps. Also all audio for all muted channels are muted. The audio's are not automatically paused. Instead applications are expected to listen to the "mutedchanged" event and call pause() as they see fit, for example if they want to resume music where it was when the music was muted.
When muteBelow is called, it changes the mutedChannels property of all AudioChannelManager instances in all apps. Also all audio for all muted channels are muted. The audio's are not automatically paused. Instead applications are expected to listen to the "mutedchanged" event and call pause() as they see fit, for example if they want to resume music where it was when the music was muted.


Likewise, when when the user leaves an app, the mutedChannels property changes to include all channels.
Likewise, when when the user leaves an app, the mutedChannels property changes to include all channels.


The
If two or more apps call muteBelow, the mutedChannels property of all apps are set to the union of the muted channels.
 
Whenever the mutedChannels property is changed, the "mutedchange" event is fired. Note that it's only fired if the property actually changes. So if A first calls muteBelow("telephony") and then app B calls muteBelow("notification"), only the first call will result in "mutedchange" events being fired. If app A then calls unmuteAll() then the mutedChannels property changes to just include "normal" and the "mutedchange" event is fired again. Once app B calls unmuteAll() mutedChannels changes to an empty list and "mutedchange" is fired again.
 
For apps that want to keep being able to play audio when the user leaves the app, the app can call requestWakeLock("audio") to grab an "audio" wakelock. As long as the app holds the "audio" wakelock its mutedChannels property won't change due to the user leaving the app. The mutedChannels property can of course still change if another app calls muteBelow("...").
 
== System app API ==
 
We'll have to change the power API so that the power API exposes which app has grabbed a particular lock.
 
We need to enable the system app to know any time an app sets the volumeControlChannel property. A simple solution would be to fire a mozChromeEvent which indicates which app set the property and what it set the property to. That way the system app can track what value the property has in all apps and so when the volume buttons are used, the system app can know which is the visible app and what the property is set to in that app.
Confirmed users
716

edits