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 (i.e. just as
many plugins playing audio as <audio>/<video> elements).  Bikeshedding
would be arguing over whether it should be named background or lowpriority.

"Web Audio is doable" is a pretty simplistic view - it's relatively easy to
say you want to pause playback of an MP3 file, or even pause an adaptive
audio stream; however, it's harder to come up with a consistent view of
what you should do with Web Audio.  You can't pause the audio hardware's
clock; what do you do with audio changes that are scheduled to occur
(including but not limited to buffer playback scheduled in the future, and
audio parameter changes like volume or frequency ramps).  The concept of
"pausing" becomes a much higher-level one; you really need my sequencer app
to be asked to pause, not pausing the sound buffers it is playing.

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.

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.

The problem they CAN'T solve is the telephony one - intelligently pausing
sounds when a phone call comes in.  I would have expected a design that was
more like firing an event on the window that asks the app to pause all
playing audio - and in fact, I might want a video stream to go on playing
visually, but not audibly, or I might want a live stream to have its volume
reduced, but not shut off.  The default handling of this event could be to
forcibly pause all media elements, and even forcibly mute sounds playing
from Web Audio and plugins; but that handling could easily be prevented by
my app that knows it should pause the sequencing.  Or something like that -
that's a design off the top of my head, so I make not guarantees about its
completeness.

-C

* I'm using Pandora as a placeholder here; the problem is there are a huge
number of applications like Pandora, and there's no additional value today
for them to do this work, yet I don't think implementers could deploy this
until they do.


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
> >
> >
> >
>
>
>
>
>