[whatwg] Background audio channels

[Chris Wilson]

Browsers can already implement this - Chrome did, in fact.  I don't think
it would be part of the spec.

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, Apr 10, 2013 at 12:55 AM, Andrew Herrington <
a.d.herrington at gmail.com> wrote:

> If permission does not have to be requested, could we have an indicator as
> to what tab / browser is making the sound? It is frustrating to have to
> close tabs / windows until you find the one that is making the irritating
> noise. Or would this be beyond a spec?
>
>
> Kind regards,
>
> Andrew
>
>
> On 10 Apr 2013, at 02:11, "SULLIVAN, BRYAN L" <bs3131 at att.com> wrote:
>
> > I also support this proposal. 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.
> The audio API will be used for many purposes, and I'm sure it will not be
> hard to find common use cases that 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.
> >
> > Thanks,
> > Bryan Sullivan
> >
> > -----Original Message-----
> > From: Paul Bakaus [mailto:pbakaus at zynga.com]
> > Sent: Tuesday, April 09, 2013 4:56 AM
> > To: Wesley Johnston; public-html at w3.org; whatwg at whatwg.org
> > Subject: Re: [whatwg] Background audio channels
> >
> > I support this proposal  makes total sense to me. We (Zynga) promise
> > we'll not misuse the priority channels :)
> >
> > On 15.03.13 18:57, "Wesley Johnston" <wjohnston at mozilla.com> 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
> >
> >
> >
>
>
>
>