- From: Paul Bakaus <pbakaus@zynga.com>
- Date: Tue, 9 Apr 2013 11:56:12 +0000
- To: Wesley Johnston <wjohnston@mozilla.com>, "public-html@w3.org" <public-html@w3.org>, "whatwg@whatwg.org" <whatwg@whatwg.org>
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 Tuesday, 9 April 2013 11:56:47 UTC