- From: Eldar Rello via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Mar 2024 10:18:44 +0000
- To: public-webrtc-logs@w3.org
> packets are not discarded But that should be easy change. And can be done when user sets maximum delay indicating that loosing some delayed audio is ok. In syncing multiple audio playbacks scenario it is also not desirable to playout old audio, which may have already been heard from other playbacks. > if one stream is behind, why not just increase the delay on the other streams? This has been tried and works in some extent if you can predict the reason why actual playout delay is higher than the target. Otherwise there would be loop to adjusting the delay to infinity. Imagine A finds that its delay is behind B by 40ms and tells B to increase delay by 40ms. Then B instead of reaching the target precisely also leaves playout delay at +40ms. Now A needs to adjust. With some complex logic it may work in increasing the delay direction, but once the jitterBufferTarget is set the delay never starts reduce once network conditions get better. Getting the delay back to lower values is even more complex. -- GitHub Notification of comment by eldarrello Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/199#issuecomment-2006697270 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 March 2024 10:18:45 UTC