Looks good on samus. I use apprtc loopback page and play two 4K video at the same time. The longest reply time from Chrome to CRAS is about 1ms which is far below the timeout range.
I will need to test on slower boards too like peach_pit.

In normal cases we are well below 5 ms. Sometimes it can take longer than that, for example under CPU load. I've seen many timeouts in logs in bug reports. To really test the impact of this change we'd need a test case were it's pushed further than 5 ms. We don't have a deterministic automated test that does that, so it's hard to test. Nevertheless, it's great that you're doing the testing available.

Issue 487060 could possibly be a timeout issue, I'll see if I can repro that.

Running stressapptest can help stressing the device (both memory and CPU)
e.g.

stressapptest -M 100 -s 3000
(-M is memory in byte, -s is time in seconds. -m can set number of CPU. Default is the number of CPU available on system.)

It will have the same priority as renderer so it will compete CPU cycle with renderer.
But it is hard to say whether this is appropriate level of stressing. I don't think user will use CPU that intensively so I played 4K youtube instead.

I will be OOO until next week so I will test other boards then.

Thanks!

On 9435.0 / 59.0.3063.0 image, I used peach_pit to play two 4K youtube videos and use WebRTC loopback page at the same time.

There was indeed some silence when playing youtube, about 1 out of 10 minutes, but at the same time, WebRTC page works fine.

So the change in audio_sync_reader timeout works as expected ( replace pop noise with silence when system is busy), and, does not break WebRTC on slower boards.

Out of curiosity: the "pop noise", what is that? Is that random data (old audio data?) that happens to be in the buffer?

Yes, it is caused by the old data in the ALSA ring buffer.
When underrun happens, device plays what is left in the ring buffer. So there will be discontinuity in the data, and that abrupt change in the sample value usually causes pop noise.

#5, are you saying that 1 minute out of 10 was complete silence?

Also, I don't see why YouTube would be hit when WebRTC is not - the longer buffer size should make it less sensitive.

Sorry I meant the brief silence which last for less than 1 seconds happened once during my 10 minutes testing. I noticed that because the music played on youtube briefly stopped, then resumed.
I agree with you that when system is busy WebRTC should be affected. In my testing I enabled loopback and listened to what I sad. I think the brief stop was too short such that I did not notice it.

To make the test more robust I should play something to loopback page such that I can 
constantly receive something back from loopback, and listen for distortion or artifacts.
I will check if this is doable on chameleon.

What remains to do for this bug?

I have done the test using loopback from USB to headphone, and check number of audio drops using chameleon stream server.
The test setup is described in

go/chameleon-webrtc-testing

This is more reliable then using human ear.
The test looks good on peach_pit.
During 10 minutes of testing, there will be no audio drop in WebRTC loopback under one 4K youtube video load, and 4 audio drops under two 4K youtube videos load.
I think this is acceptable performance.
More testing result can be seen in the doc.
If you are interested in other test scenario I can do it with similar test environment.
Maybe olka can setup and conduct the test too since she got the Chameleon now.

Thanks!

I think we can close this one.
Thanks!

OK. Thanks for doing the tests!

srcv@: Can you verify this issue? Thanks