Breaking changes to the Audio Worklet API?

[cwoffenden]

Since I've been working with it, and making PRs such as #22753, etc., I have suggestions for breaking API changes. Instead of just going ahead with a PR, what's the right way of presenting my changes? It's not massive changes, it's just further prep for the 1.1 AW API.

[kripken]

I think a PR is the best thing, unless you want feedback before working on it, in which case an issue sounds right.

[cwoffenden]

I'll probably just write a PR for the changes, it's just I'm writing each PR on top of my previous changes, #22753 was built on the minor #22741, but this next set of changes is quite involving (API change, examples and tests) and I want to build it on #22753, which is sitting unmerged. I'll gather feedback from the API change and add the examples and tests afterwards, and I'll build on my previous PR and rebase afterwards (it just makes it harder to read).

(I want to add an extra filled struct to the AW API, containing all the things interesting to anyone writing audio code, e.g. sample rate, latency, and frame size, plus maybe changes to shorten the number of params a little.)

[cwoffenden]

The API changes are small, I'll add a struct to contain useful data valid for the duration of the callback:

https://github.com/cwoffenden/emscripten/blob/0a580b655b66e4f869e182574bc0e8693d351444/system/include/emscripten/webaudio.h#L126

Which is added to the callback:

https://github.com/cwoffenden/emscripten/blob/0a580b655b66e4f869e182574bc0e8693d351444/system/include/emscripten/webaudio.h#L140

And any of the old API will be marked as deprecated:

https://github.com/cwoffenden/emscripten/blob/0a580b655b66e4f869e182574bc0e8693d351444/system/include/emscripten/webaudio.h#L109

Sample code will be updated. The idea being being, code written against this is both future-proof when the AW 1.1 API lands (better than my non-breaking earlier PR) and allows for access to values required per audio frame.

It's debatable which parameters should be present, but at a minimum the sampleRate and renderQuantumSize will always be needed.

(This is just rough, want to write the implementation against #22753 and not main due to the number of changes.)