Repository navigation
perf(rtc-node): route audio stream events and capture callbacks by handle - #739
Open
cosmin-staicu wants to merge 1 commit into
Open
cosmin-staicu wants to merge 1 commit into
cosmin-staicu wants to merge 1 commit into
Conversation
…ndle Every FFI event was emitted to every listener in the process. Each audio stream and each room checked every other stream's frames, and every frame an AudioSource captured added a waitFor listener that all other waiters tested. Dispatch cost grew with the square of the concurrent streams; with a few dozen calls in one process it was about a third of the JS thread. Audio stream events now go to the listener registered for their stream handle, and captureAudioFrame callbacks to the waiter for their async id. A callback nothing waits for is still emitted, so waitFor callers keep working. AudioStreamSource keeps its handle id as a plain bigint, because reading the native FfiHandle.handle getter crosses into native code on every event. Room.onFfiEvent returns before taking its event lock for anything that is not a room event or an RPC invocation, the only cases processFfiEvent acts on. Signed-off-by: Cosmin Staicu <cosmin.staicu@uipath.com>
🦋 Changeset detectedLatest commit: 02b9039 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every FFI event is emitted to every listener in the process. Each
AudioStreamSourceand eachRoomchecks every other stream's audio frames, and each frame anAudioSourcecaptures adds awaitForlistener that every other waiter tests until its callback arrives. Dispatch cost grows with the square of the number of concurrent streams. In a CPU profile of one process holding 25 calls, this fan-out was about 30% of the JS thread.This PR routes the two high-volume event types directly:
audioStreamEventgoes to the listener registered for its stream handle.captureAudioFramegoes to the waiter registered for its async id. A callback nothing waits for is still emitted, sowaitForcallers keep working.AudioStreamSourcekeeps its handle id as a plain bigint, because reading the nativeFfiHandle.handlegetter crosses into native code on every event.Room.onFfiEventnow returns before taking its event lock for anything that is not a room event or an RPC invocation.processFfiEventonly acts on those two cases, and events buffered before connect were already discarded there.FfiClientis not exported, so the new methods stay internal.ffi_client.test.tsdrives the routing through a mockedlivekitInitialize. Three of its five cases fail on main.