Some more notes to add to the bug. 

When the issue happens, here're the audioElement state: 
readyState: 2 - HAVE_CURRENT_DATA,
seeking: false,
paused: false.

According to https://html.spec.whatwg.org/multipage/embedded-content.html#event-media-waiting, I'm not sure why playback stalls and waiting emits. 

If we disable the preload for track2, playback continues as expected. However, being able to preload audio buffer is important  when we play through a queue of audio tracks. We want to prefetch the upcoming track to reduce the time to play when the current track ends and the upcoming track begins. With this new issue, we cannot successfully prefetch the next track without introducing rebuffers.

Can you prioritize the issue?

Tested this issue on Mac 10.12.4 using #58.0.3029.81. Unable to reproduce this issue. Could you please review the attached screen cast and let us know if any steps missed from our side.

Thanks,

Deleted: 713858.mp4 2.1 MB

	713858.mp4 2.1 MB View Download

Here's another JSFiddle:https://jsfiddle.net/74o1hwyk/. The issue can be reproduced 100% for me. 
Just make sure you don't have the audio cached.  

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

It seems to be working as expected as far as I can tell: if you wait long enough, the browser will preload more when the playback reaches a certain point. If the assumption is that Chrome will preload the entire track, the assumption is wrong.

Let me clarify. 

The bug is when track2 is preloading, track1 stalls, regardless whether track1 has content to play. Track1 stalls even when it has preloaded more content. According to https://html.spec.whatwg.org/multipage/embedded-content.html#event-media-waiting, if track1's readyState is higher than HAVE_CURRENT_DATA, waiting event shouldn't fire. 

It's true that track1 will resume. However the WAITING event and STALL are unexpected. 

With this bug, if we want to prefetch next track in the queue, current track playback will be interrupted by a stall caused by the next track preloading. 

Can you try Chrome in previous version? 
In previous version (before 58.0.3029.81), there's no waiting event fired. And in 58.0.3029.81, waiting event is fired whenever track2 is preloaded. 

Thank you for providing more feedback. Adding requester "mlamouri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I tried on 58.0.3029.81 three times and only once the state reached 'waiting' during the playback.

+hubbe@ as it sounds like a loading issue.

Able to reproduce the issue on Windows 10, Mac 10.12.4 and Ubuntu 14.04 using reported version #58.0.3029.81 but the same is not reproducible in the latest canary #60.0.3081.6.

Reverse Bisect Information:
=====================
Good build: 59.0.3053.0  Revision(459685)
Bad Build : 59.0.3050.0  Revision(459323)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/095bbad98260feae3a161c19ca1e9d9809dd544b..83bbe324e42ebe5b1205d6caeb1ea4149bad31f1

From the above change log possible CL that fixed this issue:
Review-Url: https://codereview.chromium.org/2737653002

hubbe@ - Could you please check and merge the fix to M59 if it is a valid candidate.

Note: Adding label ReleaseBlock-Stable as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

Dropping M-59 and RBS as I was able to reproduce this in M58. The issue is a flake and most likely the regression failed because of the issue happening intermittently.

Could also be related to sharing a thread for demuxing now. 

I don't think that my CL is a good candidate for merging for M59.
While it's not very big, it wasn't meant to be a bugfix and could have subtle problems that we need time to test and find.

Furthermore, I suspect that my CL isn't actually fixing the problem, it's just making it more difficult to trigger whatever the actual bug is.

I'm going to build chrome without my change and see if I can still reproduce and fix the problem that way.

Dale; I think you're right in that the shared dmuxer thread is the crux of the problem. As far as I can tell, it's (sometimes) possible for a slow read in one demuxer to cause another demuxers to be slow as well. The 2-second readahead in my change makes this a lot better, but I'm not sure it's good enough since reads can take arbitrarily long.

Suggestions? Should we revert https://codereview.chromium.org/2710133003/ ?

No, the thread reduction is pretty valuable and the stoppage should be brief in practice.

I think your fix is sufficient for M59 and it's too late for M58.

The right overall fix here is for base::TaskScheduler to be smarter about when it spins up new threads and when it moves tasks to other threads within the blocking pool; i.e. if a task in the pool is taking too long (~hundreds of milliseconds in this case) the sequence should be reparented. +gab in case he has suggestions.

@dale: I'm happy to improve the task scheduler to help here if possible but I'm not sure I understand what you mean by "the sequence should be reparented"? Tasks that are posted in sequence inherently block each other.

FWICT, that CL made FFmpegDemuxer go from one thread per instance to one SequencedTaskRunner per instance. Unless there are enough live FFmpegDemuxer sequences to flood the pool, these should be semantically equivalent.

We are thinking of detecting when a task is blocked (descheduled and not using CPU) so that we can replace its thread in the pool with an active one. Is that what you meant by "reparenting"? How would that help here?

How many threads are in the pool?
Maybe there is actually something else going on here...

Sorry, if I wasn't clear, we are discussing two sequence instances where the second is being blocked on the first. So by reparenting I meant that if a non-dependent sequence is blocked for too long on a given thread it should be moved to another thread.

In this instance there are only two instances and we're seeing blockage, so there shouldn't be any flooding of the pool.

Yes to your last comment, that's what I was suggesting.

But yes also to hubbe@'s point in c#19, we should verify that's actually what's happening here and not some blockage on another resource (loading, etc).

A task scheduler sequence is never bound to a thread and as such never waits for another sequence unless the pool has reached its max number of active threads (in your case 8 threads minimum, potentially more depending on machine).

You can enable "task_scheduler" category in chrome://tracing to see more (you'll care about the "ForegroundBlocking" workers).

You can also look at chrome://histograms/TaskScheduler.TaskLatency.UserBlockingTaskPriority.MayBlock to get a sense of the latency of the type of tasks posted by your task runners.

Thanks for looking into the issue!

Can we have an update?

Thanks,
Hao

As far as we know, this bug is fixed in M59, which will be going live soon.
If you find that that is not the case, please update this bug.