Investigate performance imrpovement for when peerconnection audio input and output is on the same thread |
|
Issue descriptionThis was discovered as a result of the new AppRTC loopback logic in https://github.com/webrtc/apprtc/pull/346 (has now been reverted due to a couple of other issues). from olka@ We noticed that peer connection audio rendering becomes very heavy in the new loopback version: each audio rendering callback (issued once in 10 ms) takes 7-8 ms to process on my super-powerful workstation. It means that on weaker systems it may take more than 10 ms and there will be audio glitches in loopback mode. The reason is that peer connection output and input run on the same thread in this case and each render call pulls the whole pipeline. assigning to tommi@ for priority.
,
Mar 12 2018
Should we check the performance after your task queue change [1]? https://chromium-review.googlesource.com/c/chromium/src/+/890738
,
Mar 12 2018
Unfortunately much of the code that is involved here, doesn't use a task queue, so I wouldn't expect there to be a change there. |
|
►
Sign in to add a comment |
|
Comment 1 by tommi@chromium.org
, Mar 12 2018Owner: olka@chromium.org