AudioBufferSourceOptions buffer seems like it could default to null

[annevk]

I didn't see a reason this needs to distinguish between null and missing? (Although the algorithms are a bit hard to follow.)

[annevk]

This also applies to ConvolverOptions it seems.

[padenot]

2026-02-17 call:

What would be the impact of doing this vs. a default value? It's functionally equivalent in terms of Web Audio API.

We're missing some language in the ConvolverNode case, it's not clear what happens when setting the .buffer to null when it wasn't null. In Firefox this clears internal state.

[annevk]

I'm not sure I understand the question. If they are indeed equivalent it's preferable to reduce the number of branches through IDL to reduce overall complexity.

[hoch]

Teleconference on Apr 9, 2026:

• Update AudioBufferSourceOptions: Modify the Web IDL to set the default value of the buffer member to null.
• Update ConvolverOptions: Align the buffer member in ConvolverOptions to also default to null.
• Define ConvolverNode.buffer Nullification: Add explicit language to the specification detailing what happens when ConvolverNode.buffer is set to null after it has already been assigned a value (e.g., ensuring it correctly clears the internal state/impulse response).