[whatwg] AudioTrack enabling - missing behaviour in the specification

[Ian Hickson]

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 
> limitations."
> 
> 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 
or something)

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