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