Able to reproduce this issue on Mac OS 10.12 using chrome latest stable M55-55.0.2883.95 by following steps mentioned in the original comment. By clicking on the play button of 3rd audio element the 'waiting' even is fired.

Bisect Information:
--------------------------
Good build: 55.0.2871.0
Bad build:    55.0.2873.0

Change Log: https://chromium.googlesource.com/chromium/src/+log/55.0.2871.0..55.0.2875.0?pretty=fuller&n=10000

Unable to invoke bad builds during python tool bisect, so providing manual bisect information. As per the above log observing only one change which is related to Html5, Hence assigning to the same.
Review-Url: https://codereview.chromium.org/2355743005

xing.xu@ Do you have any idea on this bug? Incase of this issue is not related to your change please feel free to reassign to the concerned dev person.

Thanks! 

Patch https://codereview.chromium.org/2355743005 is about dialog, nothing to do with audio.  And http://phoboslab.org/files/html5audio/chrome-cache-bug.html didn't use dialog. So how about someone audio related check this first?

This bug appears to be fixed on the Canary version (57.0.2977.0), but not the beta version (56.0.2924.51).

Hey dgreid@, are you the right person to look into this, or do you know who is?

I'm upgrading this bug to P1 because it's currently impacting standardized testing on CrOS and we're already receiving user reports.

Way too far up the stack for me if it is happening on Mac as well.

Hey dalecurtis@, would you be the right person to take a look at this, or do you know who is?

Same problem here.. Broken on 55.0.2883.95, works well on Canary 58.0.2990.0.

This site makes 12 connections for the audio files, this exceeds the max of 6 connections for an HTTP connection. This is probably issue 58467, +hubbe in case there's anything interesting from a network perspective that we could be doing better here.

If you have assets like this you should mark the tags as preload=none, or preload=metadata to cycle down the connections. preload=auto expects that playback will begin shortly.

Seems like another bisect should be done too.

Tested in chrome stable #55.0.2883.95 on Mac 10.12.2 and able to reproduce the issue. Not able to reproduce the issue in beta #56.0.2924.67 dev #57.0.2986.0 and canary #58.0.2991.0. So providing the reverse bisect details.

Bisect Info:
------------
Good Build: 56.0.2910.0 (Revision- 430103)
Bad Build: 56.0.2909.0 (Revision- 429737)

You are probably looking for a change made after 430085 (known good), but no later than 430086 (first known bad).

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/c48a68ee1b819983e6849dbccadf33b7248db8c1..d026f79cc5949df6bae399f58128b470f8061ad7

From the CL above, assigning the issue to the concern owner. Probably this change could have fixed the issue.

@ watk : Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change.

Review-Url:  https://codereview.chromium.org/2445533002

Looks like this might be fixed by Dan's recent changes. I'd expect latest M57 to work then though.

sandersd@ and I took a look at this. This is what appears to be happening:

* We add players in the idle state initially
* RendererWebMediaPlayerDelegate performs an idle player cleanup after 8 players are added
* So sometimes this third player is idle suspended because the cleanup runs almost immediately after it's created before loading has ever progressed (last_time_loading_progressed_.is_null()). The logic it uses to accept the suspend request is:
  if (last_time_loading_progressed_.is_null() ||
        (tick_clock_->NowTicks() - last_time_loading_progressed_) >
         kLoadingToIdleTimeout)
* That should be fine, though, because the next time didLoadingProgress is called we'll resume the player.

So our hypothesis is that didLoadingProgress() is not called. This code relies on the invariant: after load() is called, if any reads succeed then didLoadingProgress will be called at least once. Looks like this isn't happening in this case. 

If you open the devtools network tab you can see different network behavior in the cases where it works and doesn't work. When it works as expected you can see network requests for the media files (beep*.ogg) (whether they're satisfied by the disk cache or not doesn't matter). When it doesn't work there are zero requests for the media files (but they're still loading from somewhere). I don't understand the latter mode. hubbe@? 

Some observations:
1. the bug cannot be reproduced inside an iframe. The last event will always be `canplaythrough`.
2. also, the bug cannot be reproduced on the `file://` protocol.
2. the devtools network tab not showing the ogg files should be treated as a separate bug. It most certainly **is** a bug, but it's not directly related to the current one.

Unable to reproduce this on ToT. Seems very likely that Dan's changes fixed it.