Re: [whatwg] Background audio channels

> No, plugins are not a bikeshed at all.  They are part of the problem - in fact, I wouldn't be surprised if they're half the problem.

Yes, but I don't think they're solvable here, and its not worth holding up the entire idea trying to fix them. The best solution I know of for plugins is click-to-play, which fixes a very different problem, but helps prevent this one. It sounds, from your comments, like WebAudio needs a good definition of "pause" that happens in a reasonable amount of time. I don't know that spec at all, so feedback is appreciated. Is it an impossible problem to solve?

> The first browser that tried to "upgrade" their support by disabling Pandora* playing in a background tab, because Pandora hasn't added an attribute to their <audio>/plugins, is going to have to deal with a lot of user backlash. 

Yes. Like many web breaking changes, UA's would need to do this on a gradual roll out, perhaps defaulting it to background for some period, but monitoring/evangelizing sites to work with the new spec. If that evangelism occurs across multiple browsers/vendors, it would have stronger support. But given the response/fear here, I also won't be surprised if one vendor had to take the first steps. I would also imagine that mobile is a good starting point, since there are even fewer mobile sites that expect to work in the background than desktop. In fact, until about a month ago, Chrome on mobile already did this (and users came to us asking us to match their behavior, which I fought until sites had some way to opt out of being paused). Since Chrome already shipped this behavior, maybe you have some indication of how many sites are depending on being able to play HTML5 audio in the background?

I would guess that number is miniscule, and will quickly be dwarfed by html5 gaming frameworks (that should mute in the background). I also expect we'll see a lot more garage developers there. Again, I'd say while not ideal, its as good a time as we'll ever have to try and fix this.

> Finally, apps can already solve this problem today - they know when they go into the background (for different permutations of "background", as Jer mentioned), and they can pretty trivially mute or pause their playing audio. Most of them don't. 

Yes.... err... isn't this my point? Most of them (that I've encountered) aren't not muting themselves because they think what they're playing is so important that it shouldn't be stopped. Most of them are used to expecting the platform to do the right thing for them.

I'd love to hear better solutions. Although I've fought for it before, I don't really consider "Sites can mute themselves" a solution at this point (they won't). Neither do I think we want users to have to manually manage this. I've thrown around some ideas about events with people before, but I think this solution is much simpler for devs to implement.

Again, IMO 1.) The EVENTUAL default behavior here has to be to mute tabs in the background. History and the current situation show devs haven't/won't bother to do this on their own. Forcing them to opt in puts users back in control. 2.) I don't believe there's any need for a separation between installed/non-installed webapps here.

- Wes


On Wed, Apr 10, 2013 at 10:07 AM, Wesley Johnston < wjohnston@mozilla.com > wrote: 


Plugins are a bit of a bikeshed argument here and beyond any spec I know of? (UAs are moving towards disabling entirely or requiring click to play for plugins anyway) WebAudio is doable and should be addressed. But yes, my proposal is that we "break" all current audio elements and force the to add an attribute if they want to play in the background. Alternatively, we could default the attribute to background, but that doesn't really solve the problem. We could let the UA choose its own default (i.e. if desktop browsers want to default to "background" and mobile to "normal"). I imagine we'd roll this out on Mobile first. 

My opinion: the fact that browsers are starting to implement UI so that users can manually fix this problem indicates there is a problem, and its better to take action to fix it sooner rather than later. Manually expecting users to pause audio is a bad solution. Expecting sites to shut down audio on visibility changes is reasonable, but so far they haven't. We're approaching a situation similar to the one we formerly had with popup ads. 

Showing a permissions prompt is optional. I agree it could be annoying. 

- Wes 



----- Original Message ----- 
From: "Chris Wilson" < cwilso@google.com > 
To: "Andrew Herrington" < a.d.herrington@gmail.com > 
Cc: "BRYAN L SULLIVAN" < bs3131@att.com >, "Paul Bakaus" < pbakaus@zynga.com >, "Wesley Johnston" < wjohnston@mozilla.com >, public-html@w3.org , whatwg@whatwg.org 
Sent: Wednesday, April 10, 2013 9:37:11 AM 
Subject: Re: [whatwg] Background audio channels 


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 19:14:26 UTC