Repository navigation
Conversation
… switch setAudioBitrateProfile now awaits the audio processing toggle, the iOS stereo playout preference and the microphone recapture, and fails when the microphone could not be captured again. The call keeps the new profile then; the microphone is reported muted and picks the new constraints up when it is unmuted. RtcManager.changeDefaultAudioConstraints and RtcPublisher.restartLiveAudioTracks return a Result. Refs FLU-1176 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
|
Two quick switches could finish out of order, because stopping audio processing waits on the SFU while starting it can fail at once. The call state then said voice while the microphone captured in stereo without voice processing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
📊 Cognitive Complexity AnalysisNet Delta: +10 | Added: 2 | Increased: 1 | Improved: 1 | Removed: 0 | Violations: 0
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## v2 #1561 +/- ##
=======================================
Coverage 55.61% 55.62%
=======================================
Files 484 484
Lines 33077 33087 +10
=======================================
+ Hits 18396 18404 +8
- Misses 14681 14683 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| final stereo = profile == SfuAudioBitrateProfile.musicHighQuality; | ||
|
|
||
| if (_host.isAudioProcessorConfigured()) { | ||
| final processing = stereo |
There was a problem hiding this comment.
Awaiting this now puts an SFU round trip in front of the mic recapture: startAudioProcessing / stopAudioProcessing await _session?.notifyNoiseCancellationStarted/Stopped(), which is an SFU request. Before, it was unawaited and ran alongside the recapture. Now the recapture, and any switch queued behind _audioBitrateProfileLock, waits on it, so a slow SFU or a reconnect in progress stalls the profile switch until that request times out.
Since the toggle's result is only logged anyway, could we keep it off the critical path, e.g. leave it unawaited as before, or run it concurrently with the recapture (Future.wait) and log its failure afterwards?
There was a problem hiding this comment.
Good catch, fixed in 94aa5dd. I didn't go back to an unawaited toggle, because two quick switches could then run start/stop out of order. Instead, startAudioProcessing / stopAudioProcessing still await the local setAudioProcessingEnabled call and the state update, then send the SFU notification without awaiting it and log a failure. The switch keeps start/stop in order under the lock, and the SFU request is no longer on the critical path. I added a test where the SFU notification never completes: both switches still finish and recapture in order.
Audio processing start/stop now notify the SFU without awaiting it, so the microphone recapture and queued profile switches no longer stall on a slow SFU request. A failed notification is logged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SDK Size
Measured on |
Size BreakdownWhat each SDK adds to an empty release app, per Dart package and native library. Dart sizes are uncompressed symbol sizes. Open the This run does not measure ios. Measured on android ·
|
| Component | Size | Δ vs v2 |
|---|---|---|
native:libjingle_peerconnection_so.so |
11.96 MB | 0 |
package:stream_video |
1.11 MB | -0.0 KB |
classes.dex |
261.9 KB | 0 |
dart:@unknown |
260.1 KB | +0.0 KB |
dart:_http |
154.1 KB | 0 |
package:protobuf |
146.0 KB | 0 |
dart:mixin_deduplication |
143.8 KB | -0.0 KB |
native:libdartjni.so |
121.7 KB | 0 |
dart:io |
99.3 KB | 0 |
dart:async |
75.6 KB | 0 |
package:stream_core |
69.5 KB | 0 |
package:stream_webrtc_flutter |
55.3 KB | 0 |
package:rxdart |
54.3 KB | 0 |
package:dio |
53.2 KB | 0 |
dart:core |
52.2 KB | 0 |
| other (71) | 537.7 KB | +0.0 KB |
android · stream_video_flutter: 17.41 MB (0)
| Component | Size | Δ vs v2 |
|---|---|---|
native:libjingle_peerconnection_so.so |
11.96 MB | 0 |
package:stream_video |
1.16 MB | -0.0 KB |
package:flutter |
699.1 KB | +0.0 KB |
classes.dex |
454.8 KB | 0 |
dart:@unknown |
434.9 KB | +0.0 KB |
dart:mixin_deduplication |
362.7 KB | 0 |
package:stream_video_flutter |
205.7 KB | 0 |
dart:_http |
154.1 KB | 0 |
package:protobuf |
145.2 KB | 0 |
dart:io |
136.5 KB | 0 |
package:stream_core_flutter |
124.2 KB | 0 |
native:libdartjni.so |
121.7 KB | 0 |
assets |
118.5 KB | 0 |
package:hive_ce |
99.2 KB | 0 |
dart:@shared |
84.2 KB | -0.0 KB |
| other (99) | 1.22 MB | 0 |
Resolves FLU-1176. Follow-up from the review of #1559.
What changed
Call.setAudioBitrateProfilereturnsFuture<Result<None>>. It awaits the audio processing toggle, the iOS stereo playout preference and the microphone recapture, and returns the recapture's result.RtcManager.changeDefaultAudioConstraintsandRtcPublisher.restartLiveAudioTracksreturn aResult. They fail when a live microphone could not be captured again and was reported muted. A microphone published again during the switch is not a failure.Behaviour
Breaking (v2)
The return type of
Call.setAudioBitrateProfilechanges. Changelog line under### ⚠️ Breaking.Testing
call_audio_processing_test.dart: existing tests await the result; new tests for the stereo and mono constraints, a failed audio processing toggle being only logged, two quick switches applying in order, and a failed recapture keeping the new profile.rtc_manager_audio_constraints_test.dart: asserts the result, including the failure case.🤖 Generated with Claude Code