You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our use case (which I'm sure is common), we need to establish before the test whether the user is going to publish audio at all, and/or video at all, and if so show which device to use (front/rear camera, say). A user may be connecting just to observe the meeting without publishing anything.
In other words OT.getDevice is performed first by the calling application.
So imo the interface needs options testAudio, testVideo, audioDeviceId (use if testAudio) and videoDeviceId (use if testVideo).
It also needs to report to the calling application the open/close permission dialog events as well as the approve/deny events, so that the calling application can manage the UI appropriately.
I don't see a way to get the required user experience with the classes as presently defined. That's unfortunate, because I really don't think it should be a developer's business to fork and refactor them, but that seems to be the only option for us here.
Also the momentum towards the constraint-based mediaDevices.getUserMedia means that code relying on enumerating and selecting devices is obsolescent; at least as I understand the rather confusing portfolio of specifications.
The text was updated successfully, but these errors were encountered:
In our use case (which I'm sure is common), we need to establish before the test whether the user is going to publish audio at all, and/or video at all, and if so show which device to use (front/rear camera, say). A user may be connecting just to observe the meeting without publishing anything.
In other words OT.getDevice is performed first by the calling application.
So imo the interface needs options testAudio, testVideo, audioDeviceId (use if testAudio) and videoDeviceId (use if testVideo).
It also needs to report to the calling application the open/close permission dialog events as well as the approve/deny events, so that the calling application can manage the UI appropriately.
I don't see a way to get the required user experience with the classes as presently defined. That's unfortunate, because I really don't think it should be a developer's business to fork and refactor them, but that seems to be the only option for us here.
Also the momentum towards the constraint-based mediaDevices.getUserMedia means that code relying on enumerating and selecting devices is obsolescent; at least as I understand the rather confusing portfolio of specifications.
The text was updated successfully, but these errors were encountered: