hongchan: Could this be related to the new fifo stuff?

The provided link does not work without logging in. Do you have a repro case that is publicly available?

Hmm it is a public link -- it will try to log you in if you dismiss the blue box prompting you to wear headphones. Although, if you do have a Facebook account, I recommend that you login as the load can be very different with the rest of Facebook loaded up.

We hear clicking in the YouTube version too, although it is rare: https://youtu.be/OMLgliKYqaI

Deleted: Screen Shot 2017-08-14 at 13.47.21.png 1.8 MB

	Screen Shot 2017-08-14 at 13.47.21.png 1.8 MB View Download

nothingtokeep@

Yes, I was able to hear the sound after dismissing the login modal. Can I ask you what kind of machine you're running? I tried both MBP and MacPro and couldn't reproduce the glitch.

@hongchan config image attached, but we've heard this from many of our users across Mac and Windows machines. I have been able to recreate it by running the video in a background tab -- the glitches begin happening about 1-2 minutes in. In some cases it is continuous, in others it happens every few seconds.

Deleted: Screen Shot 2017-08-15 at 10.40.58.png 22.4 KB

	Screen Shot 2017-08-15 at 10.40.58.png 22.4 KB View Download

nothingtokeep@

Thanks for the information. I think we have to approach this problem in few different angles.

1. See the attached screenshot of Chrome DevTool + WebAudio inspector. You can see the ambisonic decoding graph is oddly huge. So the WebAudio code can be optimized. For that matter, I suggest to play the material through Omnitone (https://github.com/GoogleChrome/omnitone) to see if there is any glitch in the binaurally rendered audio. (The second/third-order ambisonic support is available on the dev branch)

2. I couldn't reproduce the glitch on any of my Macs, but I could hear few glitches on linux. Interestingly enough, the glitch seems to be associated the user interaction on the video player. So it might be the issue of user interaction. If this is the case, we are working on raising the thread priority for WebAudio, so glitch can be avoided from the heavy user interaction or the main thread operation. (issue 734539)

Deleted: Screen Shot 2017-08-15 at 11.08.58 AM.png 80.6 KB

	Screen Shot 2017-08-15 at 11.08.58 AM.png 80.6 KB View Download

@hongchang

Thanks for looking into it. That does not explain why we are seeing this issue only with v60. Previous versions of Chrome have been playing back fine -- for many months with no changes in our code. 

@hongchang

Thanks for looking into this. I did a fair bit of testing with the video posted above on Facebook, as well as it's earlier avatar on YouTube where I noticed stuttering too.

Video tested on YouTube: https://youtu.be/OMLgliKYqaI

Output recorded from Chrome v59, and v60
https://www.dropbox.com/sh/orbflnufutd697s/AAAOUYRxJKecqsJm1dKqqITUa?dl=0

Observed results: 
reeps comparison_v60 has more stuttering than reeps comparison_v59. There are multiple places to hear the stuttering clearly.
In addition, you can see from the waveforms (And through listening) how the **tempo of the song gradually drops** in Chrome v60. 

Let me know if the dropbox links don't work. Thank you for working on this with us.

Deleted: Screen Shot 2017-08-16 at 15.22.05.png 151 KB

	Screen Shot 2017-08-16 at 15.22.05.png 151 KB View Download

hongchan@
Any update on this thread?

@nothingtokeep @abesh.thaku

The fix has landed in 62.0.3196.0. Please try the latest Canary with your repro case.

hongchan@

On preliminary testing, it seems that the issues have indeed been fixed. Will let you know if we or our clients notice it once more.
Thank you so much to you and your team for fixing this and acting on the feedback. Much appreciated!