Quality events

Understanding Network and CPU utilization is crucial for optimizing video call settings and ensuring that participants remain connected and communicating through the call.

Though, modern web browsers don't provide access to CPU information for security reasons. Using call metrics, we have derived a CPU load event that can indicate when either video encoding or decoding are resulting in a high CPU load.

Additionally, detecting and responding to changes in network performance are equally important when it comes to call quality. We expose simple network events that help your application adapt to variable network conditions.

network-quality-change

The network-quality-change event applies to video calls only.

Fires when the threshold or quality of the network has changed.

threshold is an assessment of the current network quality, and can have the value 'good', 'low', or 'very-low'. The threshold value is calculated from network stats averaged over an approximately 30-second rolling window. By default, we lower the bandwidth used for the call, when the network quality drops to low.

quality is a subjective calculation of the current network quality on a scale of 1-100, suitable for display in a user interface.

The event object holds the stats for both.

network-connection

There are (currently) three possible network connection types: signaling, peer-to-peer, and sfu.

Call setup and call management information flow through the signaling network connection.

Audio and video flow through the peer-to-peer and sfu network connections.

Generally, if a participant's signaling connection is interrupted, the participant is temporarily offline. If we aren't able to reconnect within approximately 20 seconds, the participant will be ejected from the call.

When peer-to-peer and sfu network connections are interrupted, remote audio and video tracks stop, for the participant. We will attempt to reconnect peer-to-peer and sfu connections (and restore audio and video) as long as there is a live signaling connection.

The event object specifies which type of connection was affected ('signaling', 'peer-to-peer', or 'sfu'), the kind of connection event ('connected' or 'interrupted'), and any other available information, like a participant's session_id or the sfu_id.

The most common cause of peer-to-peer and sfu connection interruptions is high packet loss on the participant's local wifi network.

Dive into network connection types

cpu-load-change

The cpu-load-change event applies to video calls only.

Fires when the cpuLoadState has changed.

cpuLoadState is an assessment of the current CPU state, which can be either high or low.
cpuLoadStateReason can have values of:
- none when the cpuLoadState is low.
- encode when the cpuLoadState is high and video encoding is the primary cause for the high CPU load.
- decode when the cpuLoadState is high and video decoding is the primary cause for the high CPU load.
- scheduleDuration when the cpuLoadState is high and specific functions in the Daily code are not completing within a specified interval.

When a high CPU load occurs, this means that the video call running on your website or in your app might experience a lower resolution and/or framerate. To reduce the load on the CPU, we recommend:

lowering the outgoing video by calling updateSendSettings().
requesting a lower simulcast layer by calling updateReceiveSettings().
decreasing the amount of video subscriptions in large calls. More details on this article.

Taking these actions will result in decreased video quality, but it will help call participants remain connected and will help them to communicate without lost or delayed audio.