Handling audio-video edge cases
100ms handles a lot of standard audio/video issues internally without the developer needing to handle it explicitly. This page describes some common issues and how 100ms handles them.
There are 3 major issues of issues that can occur in a audio/video conference
- Device capture exceptions
- Network disconnection/switching network exceptions
- Network bandwidth limitation/large room exceptions
A common issue is a failure to capture mic/camera even though the user has all devices connected. Common causes include differences in OS/browser implementations of device capture APIs, permission not being granted by the user, or the device being in use by another program.
The usual recourse in these exceptions is to prompt a user action - "Grant permission", "Please close any other app using microphone", "Switch to Safari"
100ms' SDKs come with a preview method that can be called before joining a room. This will test for device failures, network connectivity and throw errors with a recommended user action.
Network disconnection/Switching networks
Another set of common issues are minor network blips. Common causes are when a user moves from one room to another, or switches from Wi-Fi to data.
100ms will send a notification within 10 s of detecting a network disconnection and will automatically retry when connection is available up to 60 s. After 60 s, a terminal error is thrown to the client.
Network bandwidth limitation/large rooms
A common occurrence in large rooms, or constrained networks is dropped frames. This results in robotic voices, frozen frames, pixelated screenshare or entire pieces of audio/video that are lost.
100ms will automatically prioritize connections if network limits are reached. This prioritization can be controlled by developers using the dashboard or 100ms APIs.
For example, a developer can prioritize host's screenshare higher than guests' videos. In low bandwidth constraints, guests' videos will be turned off, while host's screenshare will remain.