- From: Eldar Rello via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Mar 2024 09:33:13 +0000
- To: public-webrtc-logs@w3.org
Would need to write a proper explainer eventually, but for now I can reiterate some key points. The problem: synchronisation of audio playback streams in different computers. Existing jitterBufferTarget doesn't provide enough control as actual playout delay can stay at much higher value than requested target and second problem is the sharp delay jump after underrun, which ignores the target completely. If to take 1 sec delay jump as an example, which is reality in busy WIFI networks then given the 100ms per second allowed time stretching rate in NetEq, it would take ~10 sec to adapt in worst case, but 5 sec in ideal case when the 1 sec buffer also starts to accelarate at maximum rate after the glitch. Leaving the playouts out of sync for such a long periods is not feasible. As far as I understood proposal to relaxing 100ms/sec stretching limitation was also no go. Suboptimal workaround is to mute the lagging playback until it's playout delay recovers, but much better solution would be to avoid big delay jumps in the first place with help of setting max delay for jitter buffer. -- GitHub Notification of comment by eldarrello Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/199#issuecomment-2011744764 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 March 2024 09:33:14 UTC