ABSN.start sends a control message on a suspended context?

[rtoy]

Where Is It

• https://webaudio.github.io/web-audio-api/#AudioBufferSourceNode-methods
• https://webaudio.github.io/web-audio-api/#dom-audioscheduledsourcenode-start

Describe the issue
In the algorithm for start(), step 4.1 says the control message is sent to the rendering thread only if the control thread state is suspended. And control thread state says the state corresponds to the states of an AudioContext state.

Do we really mean that the message is only sent if the context is suspended? Should this not say running instead? Or maybe the state isn't the context state? Or maybe it should say something altogether different?

[rtoy]

Also, the algorithm step 2 says check for errors. This differs from the algorithm for AudioScheduledSourceNode.start() which has step 2 aborting the steps if any exception is thrown. We should update this for ABSN.

[rtoy]

Oops. Wrong repo. This is v1, I think.

[rtoy]

Teleconf: Simple typo that should be fixed.

[rtoy]

Do we need to make the distinction about the context state at all? Perhaps the messages should always be sent, letting the context deal with them appropriately?

[rtoy]

I'm confused by the conditions for sending a control message from start() for either an ABSN or other scheduled source. The text says:

5. Send a control message to the associated AudioContext to run it in the rendering thread only when the following conditions are met:

   1. The context’s control thread state is suspended.
   2. The context is allowed to start.
   3. [[suspended by user]] flag is false.

Based on these conditions, if I explicitly called context.suspend(), then any calls to start() don't send messages. When the context is resumed, none of the sources play because the control message wasn't sent.

I find this unexpected. I expect all of the sources to start playing either immediately or eventually if they were scheduled to start in the future.

If this interpretation is correct, I think the message should always be sent, implying we can remove all of the conditions.

[rtoy]

I'm further confused. Step 3 says:

Queue a control message to start the AudioBufferSourceNode, including the parameter values in the messsage.

(Note to self: Fix typo in "messsage".)

Step 5 says we send a control message to the audio thread to run it (under some conditions). But presumably, the message in 3 is eventually delivered to the audio thread, so we tell the audio thread to start the source twice. That seems wrong.

Do we really want step 5 to send directly the message to the audio thread? Shouldn't this be handled in the normal processing of the control message queue?

[rtoy]

I think I was misunderstanding what step 5 was really trying to do. I think this step is basically to allow start() to allow the context to start running if start() were called from an user gesture. I think to make it clearer, we might want to steal a bit from resume() because that's basically what this step is intended to do: resume a context that has been suspended by the autoplay policy.'

May also want to add a Note that this allows calling start() from a user gesture to start the context that is otherwise suspended.