Ensure strict ordering of resolving waitForBufferStatus calls

[lukasIO]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3494d89

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

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

[github-actions]

size-limit report 📦

Path	Size
dist/livekit-client.esm.mjs	95.53 KB (+0.11% 🔺)
dist/livekit-client.umd.js	104.35 KB (+0.1% 🔺)

[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: