Let webrtc uses block size 512 instead of minimum block size supported by Chrome |
|||||
Issue descriptionI have done webrtc testing on ChromeOS using samus board in issue 667674 . The attempt was to lower the supported block size by Chrome from 512 to 256. I tested block size 256 samples on samus and found that all of the test failures were coming from delayed callback from client. Sometimes it takes as long as 15 ms for client to reply, and this leads to underrun. This can be repro in about 10 % of tests. I guess that might be network issue. I think the best way to avoid this is to let webrtc to specify a block size it wants to use, instead of using the minimum block size supported by Chrome. For example, media player uses 1536, youtube uses 1024, they don't use minimum block size supported by Chrome because they prefer better quality than low latency. I think webrtc should do something similar, and choose block size > 512. That way, we can lower the supported minimum block size from 512 to 256 to let other app that actually wants latency as low as possible to take the benefit of the minimum block size, while webrtc still enjoy the higher block size for quality and stability. In my testing block size > 512 can pass test 100% of time without any underrun. Hi peah@ and olka@, do you think this reasonable ? Thanks!
,
Jan 20 2017
WebRTC in Chrome should be using 10 ms buffers on ChromeOS as of now: https://cs.chromium.org/chromium/src/media/base/audio_latency.cc?dr=CSs&sq=package:chromium&rcl=1484885798&l=90 Do you see it always using 256 samples instead? Is it a release build of Chrome? Who is the "client" here? How do you observe the delays? **The problems you see may be caused by apprtc loopback mode, which can under-perform due to threading specifics (+jansson@ to comment on that).
,
Jan 23 2017
,
Jan 23 2017
Hi olka, Thanks a lot for the explanation. Sorry! I misunderstood how webrtc choose the buffer size. Thanks for the pointer to the code. I thought webrtc was using the lowest value chrome supports (512), so I used --audio-buffer-size=256 args to change buffer size in the test. Actually I should build a chrome with the change media/audio/cras/audio_manager_cras.cc -const int kMinimumOutputBufferSize = 512; +const int kMinimumOutputBufferSize = 256; and see what buffer size webrtc will use. I was using a release build chrome 55.0.2883.105 on 8872.76.0 image. I checked cras's audio thread log to see the delay. It logs the time cras sent the fetch request, and when that fetch request was replied. So by client I mean cras's client, which is chrome in this case. I will check with local built chrome. It should not change webrtc's block size and behavior given that webrtc always use 10ms buffer on ChromeOS. Thanks a lot!
,
Jan 23 2017
Re AppRTC: AppRTC loopback using two peerconnections and mediaStream cloning is still reverted.
,
Jan 23 2017
I have verified that after changing kMinimumOutputBufferSize, webrtc uses 480 block size (10 ms). The test result looks good. I passed audio_AudioWebRTCLoopback.quality test 20 times in a row. I think we can close this. Thanks for the help! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by grunell@chromium.org
, Jan 20 2017Status: Assigned (was: Unconfirmed)