[whatwg] autobuffer on "new Audio" objects

On Fri, Jul 31, 2009 at 3:06 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

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

Agreed. If you want sounds on your UI, or you want to create a game using
the canvas tag, you need to be able count on your sounds being loaded the
same way you count on your images being loaded. I suspect those 2 use cases
will be far more common than the streaming use case.


>
> --
> "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
> 53:5-6]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090731/e024aa14/attachment.htm>

Received on Friday, 31 July 2009 15:38:31 UTC