Re: [whatwg] Background audio channels

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 07:56:22 UTC