Looking at the task manager I can see 39 - 87% CPU use from the Browser. No idea where the time goes into...

This was total echo, I was in the meeting.

Feedback page:

https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=Hangout&lRSearchStart=1506441600000&lRSearchEnd=1506614400000&lReport=74488000175

In chrome log, media_stream_audio_processor was complaining about large capture delay.

chrome_system_log=<multiline>
---------- START ----------
NING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1050ms; render delay: 27ms
[1:13:0927/172948.111609:WARNING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1050ms; render delay: 27ms
[1:13:0927/172948.121679:WARNING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1051ms; render delay: 27ms
[1:13:0927/172948.131609:WARNING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1050ms; render delay: 27ms
[1:13:0927/172948.141469:WARNING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1049ms; render delay: 27ms
[1:13:0927/172948.151448:WARNING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1049ms; render delay: 27ms
[1:13:0927/172948.161519:WARNING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1050ms; render delay: 27ms
[1:13:0927/172948.171479:WARNING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1049ms; render delay: 27ms
[1:13:0927/172948.181520:WARNING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1050ms; render delay: 28ms
[1:13:0927/172948.191455:WARNING:media_stream_audio_processor.cc(830)] Large audio delay, capture delay: 1049ms; render delay: 27ms


In audio thread log, we see hw_level is over 50000.

Either client did not read those samples in time, or the device capturing rate was too high.


      2170.747408740  DEV_SLEEP_TIME                 dev:9 wake:000002170.766408446
      2170.747408921  DEV_SLEEP_TIME                 dev:10 wake:000002170.750786113
      2170.747409317  SLEEP                          sleep:000000000.003383066 longest_wake:057224774
      2170.750802995  WAKE                           num_fds:0
      2170.750826226  READ_AUDIO_TSTAMP              dev:10 tstamp:000002170.750826053
      2170.750831268  READ_AUDIO                     dev:10 hw_level:50400 read:0
      2170.750831482  READ_AUDIO_DONE                read_remainder:0

However, the log was too short so we can not tell what caused that high hw_level.

Hi srcv, have you seen this issue in the testing on samus ?
I could not reproduce this. Maybe you can try it ?

Thanks!

+solenberg for Chrome audio pipeline.

I could not reproduce this issue on Samus with M61 61.0.3163.108 / 9765.72.0 beta