[whatwg] AudioTrack enabling - missing behaviour in the specification
ian at hixie.ch
Tue Jul 16 16:35:30 PDT 2013
On Tue, 18 Dec 2012, Aleksander Wabik wrote:
> Current AudioTrack spec says:
> "The AudioTrack.enabled attribute, on getting, must return true if the
> track is currently enabled, and false otherwise. On setting, it must
> enable the track if the new value is true, and disable it otherwise. (If
> the track is no longer in an AudioTrackList object, then the track being
> enabled or disabled has no effect beyond changing the value of the
> attribute on the AudioTrack object.)"
> This leaves us no place for disabling tracks by the player.
It would be fine for the player's user interface to offer a way to enable
or disable specific audio tracks.
> Tracks can only be enabled by the web application, and when enabling
> multiple audio tracks at once, they all have to be played. The
> specification does not define in any way what should happen when there
> are not sufficient resources to enable all requested tracks, and it's
> especially important on embedded systems ([smart]phones, TVs, etc).
> The spec says only:
> "User agents may impose implementation-specific limits on otherwise
> unconstrained inputs, e.g. to prevent denial of service attacks, to
> guard against running out of memory, or to work around platform-specific
> This is unfortunately not enough. The spec should require a certain
> behavior when running out of audio tracks, so that we don't end up with
> one browser enabling the newest track while another browser rejects the
> newest track, for instance.
Regardless of what we do, unless we require a specific limit that all
browsers can and do implement, we'll end up with some browsers playing all
the tracks, and some not. Regardless of which tracks are not playing, that
seems like it's a pretty bad interoperability problem. I don't see how
specifying which tracks are to be disabled would help. In particular, what
if some tracks are more expensive to play than others on some hardware?
The requirement is that you play all the enabled tracks. If you fail to do
that, you're not going to have a good time.
> To me the most natural behaviour would be to always enable the track
> which was requested to enable and, if needed, disable the least recently
> enabled track.
What if you can't play the most recently requested track, e.g. because it
is in a format that your hardware can't handle? (e.g. too great a bitrate
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg