[whatwg] autobuffer on "new Audio" objects

[Ian Hickson]

On Fri, 31 Jul 2009, Nils Dagsson Moskopp wrote:
> Am Freitag, den 31.07.2009, 00:26 +0000 schrieb Ian Hickson:
> > On Mon, 20 Jul 2009, Nils Dagsson Moskopp wrote:
> > > 
> > > I second that motion, not only as owner of a smartphone, but also as 
> > > someone with webspace that has a volume cap. Automagic audio element 
> > > buffering could deter web authors from dynamically putting more than 
> > > one element on a page, thus reserving javascript playlist widgets to 
> > > those who can afford more bandwith on an order of magnitude (!).
> > 
> > This doesn't apply to elements on the page, only to script-created 
> > elements.
> 
> I was referring to exactly that. Creating an <audio> element for every 
> audible file in a directory isn't something one would necessarily do on 
> the server side.
> 
> But as long as there is a possibility to not trigger buffering when 
> creating media objects, all may be well.

The idea of the attribute is to ensure the UA has the final say on this 
stuff, rather than having scripts that force buffering by seeking to a 
bunch of places in the file or something equally asinine.


On Fri, 31 Jul 2009, David Wilson wrote:
> 
> I still don't understand the 'why' of this, whereas the 'why not' seems 
> clear. It might be useful (in a "saving an extra line of code" kind of 
> way), but the fact it implicitly causes potentially high bandwidth IO 
> seems more wasteful than convenient.

The benefit is that most authors won't notice if they forget to include 
the attribute, and this would lead to stuttering on slow connections.


> What about adding an autobuffer parameter to the constructor which 
> defaults to false?

I think this would have the same effect as not including the argument at 
all, since most authors wouldn't think about it.


> >> I don't think the intent of creating Audio instances clearly always 
> >> means playback will happen.
> >
> > What other use cases do you have in mind?
> 
> The playlist example given doesn't seem that unreasonable, it's 
> something an unsuspecting developer might do in a hurry.
> 
> It's a good idea to make types as general as possible, particularly for 
> browsers where libraries like jQuery make it convenient to treat DOM 
> nodes as data structures. Forcing a user to type extra 
> ("document.createElement('audio')") in order to avoid surprising 
> functionality doesn't seem right.

I think there is some merit to this line of argumentation, yes. I don't 
think it outweighs the concern over sound effects stuttering, though, 
especially since the only disadvantage in the playlist case will be that 
the audio is prebuffered, leading to a better experience in that case too.


> >> It's easy to see how some naively implemented JS audio widget could 
> >> fetch 200mb over an expensive 3G connection, simply by navigating to 
> >> some site in a background tab (say, by creating an array of elements 
> >> to represent their playlist - something I'd have thought was 
> >> perfectly valid behaviour).
> >
> > A mobile phone would not autobuffer in a background tab
> 
> 3G doesn't mean mobile phone. I barely use my phone's browser, but use 
> net via Bluetooth all the time, various Dell laptops come with 3G 
> available as an option built in, for many in Africa its the only 
> available network, etc.

Indeed, systems should detect these situations and not autobuffer when 
they apply.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'