Improve ordering of resolving waitForBufferStatus calls

[lukasIO]

No description provided.

[changeset-bot]

🦋 Changeset detected

Latest commit: 423cd2e

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
dist/livekit-client.esm.mjs	95.52 KB (+0.08% 🔺)
dist/livekit-client.umd.js	104.3 KB (-0.05% 🔽)

[1egoman]

@lukasIO As a heads up, I did some quick benchmarking and while this took about the same amount of time to run as my pull request, it results in a bit more of a variable delivery rate... I'm not exactly sure why though. The packet drops that occurred for in the context of both pull requests looked to generally be single packet drops for a data track frame.

This pull request:

Production:

(I ran it ~10 times and forgot to take a screenshot, but saw one run go as low as a 20% delivery rate on the second low_fps_multi_packet test)

Staging:

My pull request's current state (d1858ba), against production:

Also for completeness, the below is my pull request pre introduction of the mutex (b7153a1) against production, which has roughly the same performance characteristics:

[lukasIO]

@1egoman I've updated this as discussed to only use the event without the mutex

[1egoman]

Sweet, thanks.

If you want to move your mutex additions into another pull request I think they still may be a good idea, but I want to have our data tracks meeting next week first before opting to potentially merge that.