Allow manual operation on audio publications even with adaptiveStream enabled #634
Conversation
🦋 Changeset detectedLatest commit: 0e0272d 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 |
| if (this.isAdaptiveStream) { | ||
| log.warn('adaptive stream is enabled, cannot change track settings', { | ||
| if (this.kind === Track.Kind.Video && this.isAdaptiveStream) { | ||
| log.warn('adaptive stream is enabled, cannot change video track settings', { | ||
| trackSid: this.trackSid, | ||
| }); | ||
| return false; |
There was a problem hiding this comment.
On a different note, should there an adpativeStream mode which includes audio also? I guess it can get confusing. I was thinking a participant level adaptiveStream. If any of the video tile of a participant is visible (camera or screen share), audio is also enabled. If none are visible, audio also disabled in this mode?
There was a problem hiding this comment.
I think this might make sense for a narrow set of use cases, but also wondering if it's worth the mental overhead to reason about different adaptiveStream modes to support it.
FWIW, the adaptiveStream setting already can be passed in as a config object, so it's not too far fetched to think about adaptiveStream: { includeAudio: true } or something along those lines
There was a problem hiding this comment.
Yeah, it will increase cognitive load. Don't think it is worth it.
Previously we were restricting the
setEnabledAPI also for audio publications in caseadaptiveStreamis enabled.adaptiveStreamonly affects video publications, however.