Implement EventTarget interface

[b-ma]

Just another try compared to #52

Tried to follow your idea, seems a bit better to me indeed but there are still some convoluted things I didn't find how to work around (no big deal though, it works... :)

Note that it depends on 415 (merged)

List of all events in the spec:

• BaseAudioContext::statechange
  • AudioContext::statechange
  • OfflineAudioContext::statechange (requires OfflineAudioContext::state is not updated when calling supend and resume orottier/web-audio-api-rs#416)
• AudioContext::sinkchange
• OfflineAudioContext::complete (requires Emit oncomplete event for OfflineAudioContext orottier/web-audio-api-rs#411)
• AudioScheduledSourceNode::ended

todo later

• AudioRenderCapacity::update (not wrapped yet)
• AudioWorkletNode::processorerror (not wrapped yet)
• ScriptProcessorNode::audioprocess (not implemented yet)

[b-ma]

One thing that I found that is more a concern on the rust side, is that the first "resume" statechange event is sometimes triggered, sometimes not. I think this some kind of race condition but this is a bit weird from a user perspective.

I will try to make a failing test for that later

[orottier]

This all looks quite complicated but I guess this is due to the fact that NodeJs has no JS-alike event targets?

[orottier]

I hope this hack is only needed for the onStateChange event? Or also for other types?

[b-ma]

Hum no it seems to be required for other types as well, need to investigate further

[orottier]

One thing that I found that is more a concern on the rust side, is that the first "resume" statechange event is sometimes triggered, sometimes not. I think this some kind of race condition but this is a bit weird from a user perspective.

I could make a start with orottier/web-audio-api-rs#410 where the whole thing will be rewritten anyway

[b-ma]

This all looks quite complicated but I guess this is due to the fact that NodeJs has no JS-alike event targets?

Actually, this is quite boring because there is a compliant EventTarget implementation in Node, but then we would need multiple inheritance to inherit from both EventTarget and the NAPI classes, which is not possible in JS.

A solution is described here, but this is something internal to Node and the given "trick" is not exposed... so we have work around somehow... Maybe I could try to open an issue on the Node repo to see if there is a solution I didn't find

[b-ma]

I don't really understand why I have less tests working than you... but that was already the case before

  RESULTS:
  - # pass: 3304 (-107)
  - # fail: 1251 (-103)
  - # type error issues: 214 (-21)

Could you run the wpt see what you get?

In any case, there is already a lot (too much) done in this PR, I will merge once orottier/web-audio-api-rs#415 is released if ok for you

[orottier]

I don't really understand why I have less tests working than you... but that was already the case before

The wpt submodule is out of date on your end I think, and this was accidentally merged into main over at fd4d710

I will push the correct version and I think you should then run git submodule update --remote --merge

I now notice we have a fatal wpt crash at

node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^
Error {
  message: 'assert_equals: state on suspend fulfilled. expected "suspended" but got "running"',
  stack: '    at http://127.0.0.1:53923/webaudio/the-audio-api/the-audiocontext-interface/suspend-after-construct.html:53:5\n' +
    '    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)'
}

So I don't have the results right now, will look into it later today

[orottier]

In any case, there is already a lot (too much) done in this PR, I will merge once orottier/web-audio-api-rs#415 is released if ok for you

I have just released v0.40.0 for you

[b-ma]

Thanks!

Seems that it was the wpt that was not up to date indeed.

For the error you encounter, I don't really understand this works well on my side. But I have seen yesterday that building in debug mode could create weird errors and crashes with wpt, I updated the wpt script (npm run wpt) so that it build in release mode, a bit longer but no strange issues of that kind, and we can always run npm run wpt:only to bypass the build step if needed.

Updated results on my side are:

  RESULTS:
  - # pass: 3605 (+192)
  - # fail: 1284 (-69)
  - # type error issues: 234 (-1)