23505 2013-10-14 20:13:36 +0000 <video>: a mechanism by which pages can indicate if their audio should play in the background 2015-09-16 11:24:36 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED MOVED P3 enhancement Needs Impl Interest 1 ian ian annevk eric.carlson ian mike philipj contributor oldest_to_newest 94696 0 ian 2013-10-14 20:13:36 +0000 On Fri, 15 Mar 2013, Wesley Johnston wrote: > > In most situations, when the user puts a webpage in the background, any > media being played by the page should be paused. Any attempts to play > audio by a background page should also be prevented. However, for some > sites (music or radio apps) the user would like to continue to hear the > app while they do something else. These pages should be able to > designate their audio as a type that should keep playing while in the > background. The useragent should also attempt to avoid having the stream > killed by the operating system if possible. This is especially true on > mobile devices, but the problem is also already prevalent on desktop. > > I think semantically we need a way to describe to the useragent how to > play a particular track. I'd suggest we add an optional attribute to > media elements, "audiochannel", designating the output and priority of > this audio. The channel attribute can potentially take on three > different values. "normal", "background", and "telephony". > > "normal" channels are the default for all media elements. Using them > doesn't require any special permissions. Audio playing with these > channels is paused when the web page moves into the background. In > addition, calling play on an media element with this channel while in > the background will put the element into the paused for user interaction > state (i.e. playback won't start until the webapp is brought to the > foreground)? > > "background" channels will continue to play when the page is put into > the background. Trying to play a background channel while in the > background should also work. The ability to play audio on this channel > may require requesting permission from the UA first (i.e. possibly a > prompt when the audio is first played or when moving to the background). > If the user doesn't grant permission, these should throw a MediaError > (MEDIA_ERR_CHANNEL_PERMISSION_NOT_GRANTED?) so that the page can know > what has happened and do something appropriate. > > "telephony" channels are similar to "background" channels and can play > even if the page is in the background. Playing audio on a telephony > channel may cause any audio playing on "normal" or "background" channels > to be paused or have their volume severely decreased. They also, on > devices where its supported, will likely play over handset speakers > rather than normal speakers. Similar to "background", these may require > permission from the UA. > > Note: This is all based rather loosely on the AudioChannels > implementation written for B2G recently [1]. It includes a few other > use-cases on its wiki page, along with definitions of additional > channels to accomadate them. I've been trying to simplify it down to > handle the most common use cases. Finding the correct terminology here > is difficult though. For instance, it seems likely that games will see > the background channel and think its an appropriate place to play game > background music, the exact type of audio you'd like to have paused when > you leave the game. Ideas for better ways to describe it are welcome. > > [1] https://wiki.mozilla.org/WebAPI/AudioChannels On Sat, 16 Mar 2013, James Ross wrote: > > For comparison, Windows 8 defines msAudioCategory > (http://msdn.microsoft.com/en-us/library/windows/apps/hh767375) with > similar channels to the B2G list, but also a separate msAudioDeviceType > (http://msdn.microsoft.com/en-us/library/windows/apps/hh767376) which > specifies which device to output to (console - not sure what this means, > multimedia, communications). On Wed, 10 Apr 2013, SULLIVAN, BRYAN L wrote: > > There are other use cases (e.g. a web-based tutorial or help system, intended > to guide the user in using other apps or device features) which will need > background audio capability. > > I'm not sure about the permissions based approach though. The number of > things that the user has to explicitly allow and manage seems to be > steadily increasing. Audio seems a fairly innocuous thing that I think > should be able to run in the background without any special permission. > The user always has the choice to not use the app if it doesn't offer > (or act upon) app-based controls on background audio use. On Wed, 10 Apr 2013, Chris Wilson wrote: > > Changing the default behavior of media elements today seems problematic; > all current <audio> elements, under this proposal, would start pausing when > you switched away from the tab. Additionally, this isn't just media > elements - it needs to also affect Web Audio, as well as any plugins. That > becomes a lot more problematic as well. On Wed, 10 Apr 2013, Chris Wilson wrote: > > The problem [pages] CAN'T solve is the telephony one - intelligently pausing > sounds when a phone call comes in. I would have expected a design that was > more like firing an event on the window that asks the app to pause all > playing audio - and in fact, I might want a video stream to go on playing > visually, but not audibly, or I might want a live stream to have its volume > reduced, but not shut off. The default handling of this event could be to > forcibly pause all media elements, and even forcibly mute sounds playing > from Web Audio and plugins; but that handling could easily be prevented by > my app that knows it should pause the sequencing. Or something like that [...] This topic was relatively controversial, and only selected positive comments are included above. For the full story, see the feedback here: http://lists.w3.org/Archives/Public/public-html/2013Apr/thread.html#msg49 94700 1 ian 2013-10-14 20:24:00 +0000 On Fri, 5 Apr 2013, Mounir Lamouri wrote: > > The channel attribute gives a hint about the type of channel the author > is expecting the UA to use. It is an enumerated attribute that uses the > following keywords and states: > > Keyword: media > State: Foreground Media > Fallback: none > Description: To be used for media element that wants to play basic media > such as an audio or video stream that should be paused when the page is > put in the background. > > Keyword: background-media > State: Background Media > Fallback: Foreground Media > Description: To be used for media element that wants to play basic media > such as an audio or video stream that should not be paused when the page > is put in the background. Music, podcast or radio players are expected > to use this state. > > Keyword: effects > State: Effects > Fallback: Foreground Media > Description: To be used for media element that creates short and quick > effects such as button click, game effects. It is intended to be used > for effects that are being heard while using the page, not for > notifications. When on this state, the media should use a low latency > channel. > > Keyword: notification > State: Notification > Fallback: effects > Description: Like the effects state, this intends to be used for short > and quick media but that require to catch user attention whether the > page is currently visible or not. For example, this state could be used > for a sound notification when there is a new email in the user's inbox. > > Keyword: communication > State: Communication > Fallback: Background Media > Description: To be used for media element that transmits real time > communication such as phone calls or VOIP. When on this state, the media > should use a low latency channel. > > Keyword: alarm > State: Alarm > Fallback: Notification > Description: To be used for media element that wants to make sure to be > played even if the device is currently muted. Typical use case would be > an alarm clock. The above is an extract from: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0026.html 123222 2 annevk 2015-09-16 09:54:38 +0000 Philip, this is the Media Session Standard, right? 123225 3 philipj 2015-09-16 11:24:36 +0000 Yes, the use cases described are what https://mediasession.spec.whatwg.org/ is trying to solve, so I'll resolve this as moved. Further feedback in this area should be directed to https://github.com/whatwg/mediasession/issues