- From: Chris Wilson <cwilso@google.com>
- Date: Wed, 10 Apr 2013 09:37:11 -0700
- To: Andrew Herrington <a.d.herrington@gmail.com>
- Cc: Paul Bakaus <pbakaus@zynga.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>, "SULLIVAN, BRYAN L" <bs3131@att.com>, "public-html@w3.org" <public-html@w3.org>, Wesley Johnston <wjohnston@mozilla.com>
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@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@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@zynga.com] > > Sent: Tuesday, April 09, 2013 4:56 AM > > To: Wesley Johnston; public-html@w3.org; whatwg@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@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 > > > > > > > > > >
Received on Wednesday, 10 April 2013 16:37:43 UTC