It's unfortunate this ends up causing glitches, it was assumed safe at the time since this was how all of Chrome's audio stack worked prior to the select() based mechanism I introduced. 

In a custom release build on Linux, were I force that code path (removing the if statement for checking the handle value), it's reproduced 100 % using WebRTC. It doesn't happen with a media element (e.g. YouTube video) or with WebAudio. ossu@ could repro on Mac, but only fairly reliably with a debug build iiuc.

And thanks Dale for the history in comment #1.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b464b3efcea3392d5254e4bb55053916801fcef7

commit b464b3efcea3392d5254e4bb55053916801fcef7
Author: grunell <grunell@chromium.org>
Date: Tue May 23 11:15:26 2017

Change SyncSocket::ReceiveWithTimeout() to use poll() instead of select() on Posix platforms.

Removing the special case for fd > 1023 which can lead to audio glitches.

Code originally written by ossu@.

BUG= 722720 

Review-Url: https://codereview.chromium.org/2888403005
Cr-Commit-Position: refs/heads/master@{#473856}

[modify] https://crrev.com/b464b3efcea3392d5254e4bb55053916801fcef7/base/sync_socket_posix.cc

I have tested to go over 1023 FDs with appr.tc; no issues observed.

Thanks for the fix! When will this roll out to the stable channel?

Beta is expected early-mid June, stable end of July.

Is it possible to switch track for a CrOS device to e.g. Canary? It'd be great if you could help us verify this fix, Chris!

It is possible: https://support.google.com/chromebook/answer/1086915?hl=en

Note that when switching back to a more stable channel, all data will be erased. That is probably not true when the device is managed, it seems like that on the description.

Is this fix in Version 60.0.3100.0 (Official Build) dev (64-bit) version? If not what version will it be in?

Re #10: it's not in that version. It will be in the next Canary and Dev. For ChromeOS it's Dev.

I think that enough people have been able to reproduce this issue that I'll let them verify the fix (I use the stable channel), though it seems that Henrik has already verified it.

I've contacted a number of people who had glitches fairly recently to ask if someone is willing to verify in Dev channel.

The fix is in 60.0.3109.0.

Any data or reviews that indicate the impact of this fix?

We only have data up to Dev so far; too little time in Beta yet. No change in the stats (Media.AudioRendererAudioGlitches and Media.AudioRendererMissedDeadline) can be seen, but that is not unexpected. I suspect this is because it is rare and when you get it you probably stop playout quickly. And if the issue persists you likely take some workaround action to fix it like restart the browser.

From those who have reported glitch issues and have tested in Dev I had no report so far of glitches. I'll follow up again with them this week.

Issue 583351 has been merged into this issue.

Issue 487060 has been merged into this issue.