feat(AudioPlayback)!: play one voice message at a time, across the whole app - #3287
Conversation
|
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 ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Size Change: +968 B (+0.12%) Total Size: 822 kB 📦 View Changed
ℹ️ View Unchanged
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## release-v15 #3287 +/- ##
==============================================
Coverage ? 84.93%
==============================================
Files ? 521
Lines ? 15338
Branches ? 4894
==============================================
Hits ? 13027
Misses ? 2311
Partials ? 0 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
🎯 Goal
allowConcurrentAudioPlaybacklet two voice messages play over each other, which is noiserather than a feature. Removing it is not enough on its own: the flag was scoped to one
audio-player pool, and
ChannelandThreadmount a pool each, so a channel and a threadbeside it played simultaneously whatever the flag said.
Exclusivity moves to a new
AudioPlaybackArbiter, provided byChat, which owns the singleAudioelement and decides who may play. Pools stay per surface, because that is what stops athread's audio when it closes while letting a message scrolled out of a virtualized list keep
playing.
That per-surface cleanup had a hole:
Channelstopped keying its subtree on the cid in v15, soa channel switch is a re-render rather than an unmount and the pool was never cleared -- audio
from the channel you left kept playing.
WithAudioPlaybackgainsplaybackScope, whose changeclears the pool;
Channelpasses its channel andThreadits thread.Threadis redundanttoday because a key on
ThreadInnerremounts it, but the code already contemplates removingthat wrapper, and the cleanup should not depend on it.
Dropping the flag also collapses the pool's dual mode: the per-owner element map, the branches
in acquire/release, and the tests parameterized over both are gone.
AudioPlayerPoolandAudioPlaybackArbiterstay internal -- an arbiter can only be consumed by the pool, soexporting it would publish a name nothing public can accept.
BREAKING CHANGE:
ChannelProps.allowConcurrentAudioPlayback,ThreadProps.allowConcurrentAudioPlaybackandWithAudioPlaybackProps.allowConcurrentPlaybackare removed, with no replacement. If you passed
true, delete it: starting a player now pauseswhichever was playing and takes the shared element over. If you passed
falseor nothing, theonly change is that playback is exclusive across surfaces rather than within one.
BREAKING CHANGE:
useActiveAudioPlayer()now reports the app-wide active player rather than thecalling surface's.