Re: [whatwg] autobuffer on new Audio objects
On Fri, 31 Jul 2009, Nils Dagsson Moskopp wrote:
Am Freitag, den 31.07.2009, 00:26 + 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] autobuffer on new Audio objects
Am Mittwoch, den 12.08.2009, 00:05 + schrieb Ian Hickson: On Fri, 31 Jul 2009, Nils Dagsson Moskopp wrote: Am Freitag, den 31.07.2009, 00:26 + 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. Oh, now I get the similarity to the autoplay attribute. No further questions, your honor and thanks for taking your time to explain this. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] autobuffer on new Audio objects
From: Ian Hickson i...@hixie.ch Sent: Thursday, July 30, 2009 7:26 PM On Mon, 20 Jul 2009, David Wilson wrote: 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 is becoming more common for computers or laptops, as well as natively in some netbooks. 200MB would cost me a couple dollars, when I expect most sites to be almost free. (I've actually had this problem when friends post The Daily Show's embedded player, which autobuffers -- unlike YouTube videos.) 3G is easier to carry around, and I see it becoming far more common in the future (especially after 4G comes), which would suggest keeping large transfers as opt-in as possible.
Re: [whatwg] autobuffer on new Audio objects
2009/7/31 Ian Hickson i...@hixie.ch:
On Mon, 20 Jul 2009, David Wilson wrote:
2009/7/19 Ian Hickson i...@hixie.ch:
On Mon, 6 Jul 2009, Robert O'Callahan wrote:
When script creates an audio element using the new Audio constructor,
the 'autobuffer' attribute should be automatically set on that element.
Presumably scripts will only create audio elements that they actually
intend to play.
Done.
This seems like surprising behaviour (and a nasty asymmetry between
markup and JS): for the savings of a single line of code, creating a
new element will automatically result in (high bandwidth) network IO.
Only if the user agent honours the autobuffer attribute. It doesn't have
to.
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.
What about adding an autobuffer parameter to the constructor which
defaults to false?
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.
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.
David
--
Reality is that which, when you stop believing in it, doesn't go away.
— Philip K. Dick
Re: [whatwg] autobuffer on new Audio objects
On Sat, Aug 1, 2009 at 12:20 AM, David Wilson d...@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 -- 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]
Re: [whatwg] autobuffer on new Audio objects
On Fri, Jul 31, 2009 at 3:06 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Aug 1, 2009 at 12:20 AM, David Wilson d...@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]
Re: [whatwg] autobuffer on new Audio objects
On Mon, 20 Jul 2009, David Wilson wrote: 2009/7/19 Ian Hickson i...@hixie.ch: On Mon, 6 Jul 2009, Robert O'Callahan wrote: When script creates an audio element using the new Audio constructor, the 'autobuffer' attribute should be automatically set on that element. Presumably scripts will only create audio elements that they actually intend to play. Done. This seems like surprising behaviour (and a nasty asymmetry between markup and JS): for the savings of a single line of code, creating a new element will automatically result in (high bandwidth) network IO. Only if the user agent honours the autobuffer attribute. It doesn't have to. 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? 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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] autobuffer on new Audio objects
Am Freitag, den 31.07.2009, 00:26 + 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. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] autobuffer on new Audio objects
On Mon, 20 Jul 2009 07:06:32 +0200, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Am Montag, den 20.07.2009, 05:46 +0100 schrieb David Wilson: 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). 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 (!). I believe the burden of writing another line should solely be on those who want autobuffering, to prevent unneccessary bandwith consumption. Cheers Regardless of whether the spec mandates that the autobuffering attribute be set for new Audio(), browsers that want to be competitive on mobile will have to be conservative with bandwidth. autobuffering is only a hint and doesn't need to be obeyed where it doesn't make sense (in fact can't be obeyed because the disk cache is too small). -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] autobuffer on new Audio objects
On Mon, Jul 20, 2009 at 4:46 PM, David Wilson d...@botanicus.net wrote:
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).
In your case even desktop Firefox is smarter than you think. We have a
tunable cache size which we won't download beyond until you free up space by
playing cached data. It's 50MB by default. On mobile we'd obviously reduce
that quite a bit.
I don't think your playlist example is compelling. DOM objects aren't good
for building playlists or other data structures. On the other hand,
var shotSound = new Audio(shot.wav);
...
function shoot() {
shotSound.play();
...
}
should work reliably. For small sounds, leaving out 'autobuffer' may not be
noticed on some browsers, since we have to download metadata and depending
on network conditions we often get the whole file before we start to
throttle the download for non-autobuffer elements.
Rob
--
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]
Re: [whatwg] autobuffer on new Audio objects
On Mon, Jul 20, 2009 at 5:06 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net 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 (!). document.createElement(audio) still creates a bare element. Rob -- 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]
Re: [whatwg] autobuffer on new Audio objects
On Mon, 6 Jul 2009, Robert O'Callahan wrote: When script creates an audio element using the new Audio constructor, the 'autobuffer' attribute should be automatically set on that element. Presumably scripts will only create audio elements that they actually intend to play. Done. On Sun, 5 Jul 2009, Adam Shannon wrote: What about slower, public, or WIFI connections that can't support 5 people going to yahoo.com and having audio of interviews load? Yahoo would think that everyone would want to listen to at least the first ~15-30 seconds. On Mon, 6 Jul 2009, Robert O'Callahan wrote: What about them? I'm not sure what your point is. I think we expect new Audio to be used for scripted playing of sounds, not to create in-page audio elements. On Sun, 5 Jul 2009, Adam Shannon wrote: There already low bandwidth would be crippled more than it already is. (By loading audio files. I would love support for in-page audio, it could be used for podcasts, radio, interviews, ect... On Mon, 6 Jul 2009, Robert O'Callahan wrote: For in-page audio, put an audio element in the page. Robert is right; inline audio handles this fine, and is distinct from new Audio(). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] autobuffer on new Audio objects
2009/7/19 Ian Hickson i...@hixie.ch: On Mon, 6 Jul 2009, Robert O'Callahan wrote: When script creates an audio element using the new Audio constructor, the 'autobuffer' attribute should be automatically set on that element. Presumably scripts will only create audio elements that they actually intend to play. Done. This seems like surprising behaviour (and a nasty asymmetry between markup and JS): for the savings of a single line of code, creating a new element will automatically result in (high bandwidth) network IO. I don't think the intent of creating Audio instances clearly always means playback will happen. 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). David On Sun, 5 Jul 2009, Adam Shannon wrote: What about slower, public, or WIFI connections that can't support 5 people going to yahoo.com and having audio of interviews load? Yahoo would think that everyone would want to listen to at least the first ~15-30 seconds. On Mon, 6 Jul 2009, Robert O'Callahan wrote: What about them? I'm not sure what your point is. I think we expect new Audio to be used for scripted playing of sounds, not to create in-page audio elements. On Sun, 5 Jul 2009, Adam Shannon wrote: There already low bandwidth would be crippled more than it already is. (By loading audio files. I would love support for in-page audio, it could be used for podcasts, radio, interviews, ect... On Mon, 6 Jul 2009, Robert O'Callahan wrote: For in-page audio, put an audio element in the page. Robert is right; inline audio handles this fine, and is distinct from new Audio(). -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Reality is that which, when you stop believing in it, doesn't go away. — Philip K. Dick
Re: [whatwg] autobuffer on new Audio objects
Am Montag, den 20.07.2009, 05:46 +0100 schrieb David Wilson: 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). 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 (!). I believe the burden of writing another line should solely be on those who want autobuffering, to prevent unneccessary bandwith consumption. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
[whatwg] autobuffer on new Audio objects
When script creates an audio element using the new Audio constructor, the 'autobuffer' attribute should be automatically set on that element. Presumably scripts will only create audio elements that they actually intend to play. Rob -- 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]
Re: [whatwg] autobuffer on new Audio objects
What about slower, public, or WIFI connections that can't support 5 people going to yahoo.com and having audio of interviews load? Yahoo would think that everyone would want to listen to at least the first ~15-30 seconds. On Sun, Jul 5, 2009 at 7:27 PM, Robert O'Callahan rob...@ocallahan.orgwrote: When script creates an audio element using the new Audio constructor, the 'autobuffer' attribute should be automatically set on that element. Presumably scripts will only create audio elements that they actually intend to play. Rob -- 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] -- - Adam Shannon ( http://ashannon.us )
Re: [whatwg] autobuffer on new Audio objects
On Mon, Jul 6, 2009 at 12:36 PM, Adam Shannon ashannon1...@gmail.comwrote: What about slower, public, or WIFI connections that can't support 5 people going to yahoo.com and having audio of interviews load? Yahoo would think that everyone would want to listen to at least the first ~15-30 seconds. What about them? I'm not sure what your point is. I think we expect new Audio to be used for scripted playing of sounds, not to create in-page audio elements. Rob -- 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]
Re: [whatwg] autobuffer on new Audio objects
On Sun, Jul 5, 2009 at 7:58 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Mon, Jul 6, 2009 at 12:36 PM, Adam Shannon ashannon1...@gmail.comwrote: What about slower, public, or WIFI connections that can't support 5 people going to yahoo.com and having audio of interviews load? Yahoo would think that everyone would want to listen to at least the first ~15-30 seconds. What about them? I'm not sure what your point is. There already low bandwidth would be crippled more than it already is. (By loading audio files. I think we expect new Audio to be used for scripted playing of sounds, not to create in-page audio elements. If that is the purpose for the audio element then it may be missing out, I would love support for in-page audio, it could be used for podcasts, radio, interviews, ect... Rob -- 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] -- - Adam Shannon ( http://ashannon.us )
Re: [whatwg] autobuffer on new Audio objects
On Mon, Jul 6, 2009 at 1:01 PM, Adam Shannon ashannon1...@gmail.com wrote: On Sun, Jul 5, 2009 at 7:58 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I think we expect new Audio to be used for scripted playing of sounds, not to create in-page audio elements. If that is the purpose for the audio element then it may be missing out, I would love support for in-page audio, it could be used for podcasts, radio, interviews, ect... For in-page audio, put an audio element in the page. Rob -- 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]
