[whatwg] autobuffer on "new Audio" objects

Robert O'Callahan robert at ocallahan.org
Fri Jul 31 15:06:22 PDT 2009

On Sat, Aug 1, 2009 at 12:20 AM, David Wilson <dw at botanicus.net> wrote:

> I still don't understand the 'why' of this, whereas the 'why not'
> seems clear.

Because for the 99% use case of "new Audio()" --- scripts loading sounds,
and then playing them in response to events --- it's what you want. And if
authors forget to set "autobuffer", then under some network conditions (fast
networks), short sounds will play fine when play() is called because the
sound data will have arrived with the metadata before the download is
throttled, but under other network conditions (slow networks), the same
sounds will not play smoothly because not all the data will have been
preloaded. So probably authors will forget to set "autobuffer" and not
notice, and users with slow networks will suffer.

This is not hypothetical, I suggested this change precisely because I
noticed this problem happening while testing Firefox.

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.

For the 99% use case, you want to incur that I/O.

If you never want to incur it, use a browser that lets you disable
autobuffer or otherwise manage bandwidth the way you want.

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090801/a8df905c/attachment-0002.htm>

More information about the whatwg mailing list