-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show the device that's actually in use #1670
base: livekit
Are you sure you want to change the base?
Conversation
Feeds the current track (if any), and therefore device it's using into the device selection dropdown and implement a some somewhat complex logic to observe when the 'default' device has changed to a different actual devbice between when we opened it and now, and display the device we're actually using as selected instead. The comments should explain more, including the caveat that we can't do the same detective work if the device is one of several devices on the same bit of hardware. This is because is uses the same groupId comparison technique used by Livekit in `normalizeDeviceId` to do a smiliar thing.
Codecov ReportAll modified lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## livekit #1670 +/- ##
========================================
Coverage 29.94% 29.94%
========================================
Files 47 47
Lines 1877 1877
Branches 328 328
========================================
Hits 562 562
Misses 1274 1274
Partials 41 41
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering if the other PR does obsolete this?
In the other PR the track is always updated in case the default device changes. So the track in use should always be matching the device and hence have the same/correct groupId.
I am wondering if this PR in combination with the other one would lead to the following behaviour:
- default OS device is changed (actual-device-id:
a
->b
) - device id in the selected variable is still
default
- the group id of chromes default device changed to the groupId of
b
(also the label got updated to conatining the description ofb
) - track is restarted (becasue we do the group id check an see that
default
is a new device) (other PR) in this case itsb
now. - We reach the logic introduced here,
- we pass the conditions (
device.selectedId = "default"
) - we find
(d) => d.groupId === usedGroupId && d.deviceId !== "default"
(but there will be two devices with the correct groupId because the default device and the same device with deviceId = "someActualUUIDasTheID1234") - the found device will be the one where groupId == usedGroupId and deviceId will be the NOT "default" so the selector does not select the default device anymore
- chainging the device in the os again (
a
->b
) works as normal but I am not sure EC still updates the device since now it does not check anymore if the group Id of the defualt device has changed.
So I am wondering if this would break EC following the system setting on chrome after the first system setting change.
src/settings/SettingsModal.tsx
Outdated
const usedGroupId = | ||
trackUsedByRoom?.mediaStreamTrack.getSettings().groupId; | ||
const devicesWithMatchingGroupId = devices.available.filter( | ||
(d) => d.groupId === usedGroupId && d.groupId !== "default" | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to the last pr. Could the label also work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might involve comparing here which is tricky because chrome prepends 'Default: ' so we'd have to work around that and however it i18ns on the user's system.
Thinking about this topic does livekit already check if the order of the devices changes on firefox?
I am wondering if the ux would be much less broken with the following approach:
|
Co-authored-by: Timo <[email protected]>
It will switch back to device a when you change the default device in the OS a -> b -> a (I tested). The group ID of the default device should change just the same in either case.
Possibly! Do you think we should pause this and wait for product / design input? |
Then I have a thinko, just to confirm, you tested with both PR's being merged at the same. |
Considering this,
I think pushing this to the next release and asking design is a good idea. |
(and... add comments)
…im/element-call into dbkr/show_device_actually_in_use
Making draft as this is stale. |
Feeds the current track (if any), and therefore device it's using into the device selection dropdown and implement a some somewhat complex logic to observe when the 'default' device has changed to a different actual devbice between when we opened it and now, and display the device we're actually using as selected instead.
The comments should explain more, including the caveat that we can't do the same detective work if the device is one of several devices on the same bit of hardware. This is because is uses the same groupId comparison technique used by Livekit in
normalizeDeviceId
to do a smiliar thing.Fixes #1646