Can we remove live readyState requirement when starting speech recognition with MediaStreamTrack?

[beaufortfrancois]

As start(audioTrack) requires audioTrack readyState to be "live", it means the audioTrack must be playing already before calling start(audioTrack). This means web developers are always losing the first tiny parts of the audioTrack. It's a bummer. Could we do something about this and revert some of the changes in #118

The overloaded start method does the same thing as the parameterless start method except it performs speech recognition on provided MediaStreamTrack instead of the input media stream. If the kind attribute of the MediaStreamTrack is not "audio" or the readyState attribute is not "live", the user agent must throw an "InvalidStateError" DOMException and ignore the call.

FYI @evanbliu

[padenot]

Let's do this. @jib can tell us if it's problematic from a MediaStreamTrack standpoint.

[beaufortfrancois]

FYI I've opened #128

[beaufortfrancois]

This means web developers are always losing the first tiny parts of the audioTrack.

Correction: It's not always true. They can wait for the loadeddata event for example before starting speech recognition, and only then call HTMLMediaElement play().

However, I still think the specification should be updated to remove this mandatory requirement.

[padenot]

Timing isn't exactly guaranteed with HTMLMediaElement APIs, so I think your initial point is valid in practice, and I support this.

[jan-ivar]

As start(audioTrack) requires audioTrack readyState to be "live", it means the audioTrack must be playing already before calling start(audioTrack).

That's not correct. The MST readyState has only two states "live" and "ended" and is initialized to "live", so the existing prose seems right (it's basically testing the track isn't ended which is a terminal state it seems correct to throw on).

[beaufortfrancois]

@jan-ivar is right. I'll close this issue and associated spec PR. MST readyState and HTMLMediaElement readyState are different things.