We did change media pipelines in M52 and do use smaller buffers. We started using OpenSLES instead of AudioTrack for playback in most cases. Does it glitch forever or just pop a couple times and then is okay for the rest of playback?

I haven't heard of this on any other phones, so it does seem like it might be phone specific.

Thanks for the response!

It presumably pops whenever something (system load related...I still haven't nailed down precisely what that means yet) prevents the buffer from getting filled again before it is exhausted.  So, no, it's not like there is a single instance that then ripples throughout the remainder of playback, but neither is it a one-and-done situation.  A pop or two near the beginning of playback and then never again would be tolerable; this is not.  For whatever reason, sometimes it is worse than other times.  Like I said, I can have Chrome in the foreground with the audio-playing tab in the foreground and the screen of the device on, and be constantly hearing pops every few seconds.

When listening to spoken word media, it reminds me of the exact same type of artifact I would expect to hear if I were constantly dropping packets during a PCM VoIP call.  It is irritating...it's gotten to the point where I will either seek out / source the media through a different channel/app or download it for off-line playback with some other app, and I just avoid playing media in Chrome at all costs now.

I did get a chance to try a stock Sony build of Marshmallow on the phone, and it seems improved but is not cured.  On the other hand, I briefly dug out my old Nexus 4 (which has JB on it), upgraded Chrome, and repeated the experiment, and could not get the problem to happen there.  UGH.

Unable to reproduce the issue in Android. No pops or clicks sounds are observed in audio play back.

Steps Followed
1. Launched Browser
2. Navigated to http://traffic.libsyn.com/atpfm/atp237.mp3?download=true
3. No pops or clicks sounds are observed in audio play back even after using some other apps in the background. 

Chrome versions tested
61.0.3163.81
60.0.3112.116

OS
Android 8.0.0, 6.0.1

Android Devices
Pixel Build/OPR1 170623.027
SM- J710F Build/MMB29K

@nathana: Can you please have a look into the above steps and let us know if we missed any steps form our end and let us know the update.

Thanks!!

Hey Sandeep,

You didn't miss any steps. However, referring back to my exchange with Dale above, it is looking more and more as though there are additional necessary conditions which are currently unknown, and may make this somewhat system-specific. At the very least I have been unable to reproduce on Nexus 4 as stated above; I have only observed it on Sony Z5 Compact. I do not personally have a large or diverse bench of devices to test.

It cannot merely be something tweaked in the Sony builds of the Android OS, though, because no other audio-playing app has this issue on this phone, and if I downgrade to Chrome 51, problem is fixed. Dale already confirmed that some significant changes were made under the hood on Chrome for Android in version 52 with respect to audio playback (and Googling the issue suggests he was referring to the new "unified media pipeline" that brought media handling on Android under the same codebase as Chrome for desktops). It really does seem to be somehow related to this.

Even on the Z5 I am getting confusing results. As stated earlier, Marshmallow gives notably better results than Lollipop. Also, not all attempts at loading down the system have proven to be equal. If I merely press Home after starting audio playback in Chrome on Lollipop, I'd say there is a 1 in 2 chance I will hear a glitch. But if I start up a clearly system taxing app such as Geekbench and run it while Chrome is playing, to my surprise it hardly causes any problems (I might hear a glitch every 2-3 minutes).

So far, the most reliable way to reproduce extremely obvious glitches is to be running Lollipop and then launch Sony's AR Effect camera app while Chrome is playing audio. I get the most glitches (a couple seconds' worth chained together) when I press Home after AR Effects is running. However, I realize that only certain Sony devices have access to this app, so I am still in search of a universal third-party app that stresses the system in a similar way.

While just trying to give myself an extremely surface-level acquaintance with the issue(s) involved here, I was struck by how many threads I found both on the NDK discussion group as well as sites like Stack Overflow about Android developers fighting against issues with glitching audio (one such example is here, where there is also a correlation observed with CPU load:   https://groups.google.com/forum/m/#!msg/android-ndk/HP1n8fphSs0/htwlVJg7R7wJ)...probably a red herring but nonetheless interesting.

@sandeepkumars, do you have an Xperia Z5 in the test lab? We don't have one over here. It'd be good to confirm the issue beyond the reporter's device.

@nathana: It seems your device can be upgraded to Nougat, is there a reason you're sticking with Lollipop?

https://support.sonymobile.com/global-en/xperiaz5compact/kb/801930740113d1bd101599e4b9c7200796c/

I see above you mention reasons for not upgrading, but it's unlikely we'd be able to change anything here to help you soon; ~Dec for the current Chrome release even if we found the issue tomorrow.

I understand about release cycles, so no pressure & no problem there.  If this is a legit issue that we can confirm affects more than just me, though, I want to (selfishly, admittedly) help you get the little bugger killed, regardless of timetable. :)  There are other people with phones still in active use who can't (or at least can't easily) go beyond Lollipop, and the issue exists in some form or another under Marshmallow on this hardware as well, so the question is whether this extends at all beyond some Xperia models, and if not, whether this is ultimately Sony's responsibility or what.

Much like I did with Marshmallow, I will be temporarily pushing my phone to Nougat in the next day or so For Science(tm) to see if I can repro under that.  I also hope to try some more closer-to-AOSP third-party builds to see if getting away from Sony software on the same hardware makes any difference.  Finally, I will upgrade my retired Nexus 4 to official Lollipop release and see if I can detect the problem at all on there.  I will update when I have news to share.

I'd been holding onto LP for daily use in part because I have a custom kernel mod that changes the behavior of USB OTG on this phone (and which I rely on heavily) that I'm still working on bringing up on MM and N.

I should clarify, just in case my statement about me running a kernel I compiled myself freaks anyone out, that when I tested MM on the same hardware, I was using a wholly stock system with a Sony-built kernel.  In any case, my modifications to the LP kernel are not extensive and only touch the USB drivers.

Quick (?) update:

I can in fact reproduce this in Nougat on my Z5c, though again, much like MM, it is harder to reproduce.  There is definitely something about L on this platform that causes it to be more sensitive.

I don't yet have a set of steps that make this easy to repro on N, but I did notice on MM that if I have Chrome backgrounded while playing audio and I alternated between hitting the app drawer button on my launcher and then hitting the home button to close it, that this can be enough to generate a pop (either while the app drawer is drawing or while it is going away, or both).  It's not super in-your-face but it's there.  I did have system sounds turned off while I was doing this (phone set to Do Not Disturb) so it wasn't an issue of me also hearing the system generating the usual noises that it does when tapping on icons.

Haven't yet updated to L on my Nexus 4, but I had a Moto G 2013 Google Play Edition that I had forgotten about that I pulled out of the closet.  Running KitKat on it, I cannot reproduce the issue with Chrome 60.  However, I CAN repro after upgrading to Lollipop (latest official GPE firmware for this model), using the same "stress (?) test" of backgrounding Chrome and then repeatedly opening and closing the app drawer (in this case I was using Google Now Launcher, not the system default).  So I have now seen this on two separate hardware platforms.

On Z5 Marshmallow and Moto G GPE Lollipop, if I downgrade back to an older version of Chrome then the problem vanishes.  Z5 Nougat ships with Chrome 56 so I cannot test this there.

I still plan to test on Nexus 4 running Lollipop (latest release).

I was wearing headphones for all of these tests.

Again, it is subtle enough and doesn't happen enough under these other circumstances that I wouldn't be surprised if nobody else ever took notice.  It is just the most glaringly obvious on Z5 running Sony Lollipop firmware.  So if it ever gets fixed on that particular combo, it is probably safe to say at that point that it has been fixed for everything else, too.

I managed to reproduce on Nexus 4 with latest official firmware (5.1.1 LMY48T).

Again, just like on Moto G Google Play Edition, or like on Z5 firmwares past Lollipop, it is more subtle, but is definitely there.

I did the same thing on Nexus 4 that I did on Moto G:

1. Install latest official firmware, while also wiping userdata and cache, setting up phone from scratch.
2. Added my Google account to the phone & launched Play Store.
3. Updated to latest Google app.
4. Installed Google Now Launcher.
5. Updated to latest Chrome.
6. Hit Home, set Google Now Launcher as default launcher.
7. Shut down phone & restarted.
8. Plugged in headphones.
9. Launched Chrome.
10. Navigated to the Example URL for this bug.
11. Hit the Play button to start listening.
12. While audio is playing, hit Home, then repeatedly keep hitting first the App Drawer and then Home (App Drawer, Home, App Drawer, Home, App Drawer, Home, ad infinitum) as rapidly as you can while listening to the audio.

I find that roughly 25% of the time that I hit either App Drawer or Home, I hear either a pop or a slight silent gap in the audio.  I definitely encounter it more than once within the first minute of audio playback.  I also found that every once in a while (though nowhere near as often as on Z5 w/ Lollipop), keeping Chrome in foreground and just letting audio play while doing nothing else would still produce the occasional pop.

Downgrading Chrome to 51 or older eliminates this.

Downgrading phone to KitKat or lower but running latest Chrome eliminates this.

I have no idea if this is relevant, but I will note that if you install and run https://play.google.com/store/apps/details?id=com.levien.audiobuffersize on Moto G GPE or Nexus 4, the ideal buffer size returned on Lollipop is significantly lower (~200) than what is returned when running on KitKat or Jellybean (~1000+).  Z5 running Marshmallow or greater also returns a small ideal buffer size.  Interestingly, however, the test on Z5 running Lollipop returns a similarly small buffer size at the end of the tests even though at the beginning, when interrogated, the phone advertises a much larger initial one (960) relative to what the app determines it should be (usually something between 192 and 224).  This could be related to why the effect seems much greater on the Z5 running Lollipop (some kind of bug in the audio driver for the phone that was finally corrected in Marshmallow release?).

I still go back to the fact that downgrading to Chrome 51 fixes the problem even on Z5 Lollipop ROM, and that I can't make any of the other apps that generate audio do this.

It may be that even if you correct the issue for the majority of ROMs with compliant audio implementations (assuming Moto G GPE and Nexus 4 are indeed compliant), there may still be phones with ROMs out there that have bugs which still cause problems.  Just thinking out loud: assuming that it turns out that slightly increasing the audio buffer size in Chrome takes care of the issue in the majority of cases, I wonder if it still wouldn't be a good idea to add an option to chrome://flags that allows one to manually adjust the buffer size, in order to compensate for buggy ROMs?

Not sure when I will find time to do this, but I am strongly tempted to set up a build environment for Chromium for Android and play around with minor tweaks to the audio buffer size...

Yeah I've long suspected the preferred buffer size returned by Android isn't ideal for basic playback cases. On N MR1+ we use some newer Android APIs to allow us to set a 20ms buffer size. We might be able to do the same thing on older versions of Android, but I'm not sure what the impact would be. https://developer.android.com/ndk/guides/audio/audio-latency.html

I'll reach out to the Android audio folk and see what they recommend.

Has the code utilizing the newer APIs hit a public Chrome release yet?  Because at least with Nougat 7.1.1 (MR1) on my Z5 I can still reproduce pops.

I think it's in M62, can you double check with Chrome Canary? If you check chrome://media-internals you should see that the stream has something like 1024 for frame_per_buffer.

Yeah, I'll give that a go and let you know.  Definitely did not try Canary or Chromium on Nougat.  I also just realized that on 7.1 I only tested Chrome 56, because that's what came installed as a system app and I was only trying to make sure I was running version 52 or newer.

I have only been able to play with it for a few minutes, but I can confirm that so far I have been unable to reproduce the problem with Canary 63 on Nougat 7.1.  On the same device, I can go back and forth between latest stable Chrome and latest Canary and reproduce on stable but not Canary.  So I would say that you're onto something.

Some other interestingly and potentially relevant factoids:

Native sampling rate for Z5 DAC appears to be 48kHz.

On Lollipop, both Chrome stable 61 and Chrome Canary 63 show frames_per_buffer of 4800 and sample_rate of 48000, both for the controller and the active stream.  Same same.

On Nougat 7.1, Chrome stable 61 shows frames_per_buffer of 1024 on the controller, and frames_per_buffer of 192 on the stream.  Quite a bit different, but I still get pops.  sample_rate is still 48000.  *However*, Canary 63 shows frames_per_buffer of 1024 for both the controller and the stream, yet sample_rate is 44.1kHz.

Again, don't know if it is significant, but I believe the audio files I've been testing against were all sampled at 44.1kHz, so it is interesting that either Canary is now merely showing the sampling rate of the source material in chrome://media-internals, or it's not merely cosmetic and the source audio is no longer getting upsampled.

Hope this helps.

Just so it's clear, those media-internals stats were collected on Stable and Canary running on either Lollipop MR1 or Nougat MR1 on the same hardware (Z5 Compact).  I wasn't citing figures from any ol' device that happens to be running Lollipop; I realize frames_per_buffer is going to be different depending on the hardware.

"On Lollipop, both Chrome stable 61 and Chrome Canary 63 show frames_per_buffer of 4800 and sample_rate of 48000, both for the controller and the active stream." Did you mean 4800 here? I'm surprised that if 4800 is being requested we're using 1024 even on Nougat.

We may have a bug there; BT headsets might start clicking. It should max(reported_frame_size, requested_frame_size) -- though the sample rate should be 44.1kHz, since the Android audio folks recommended we skip resampling to the DAC rate and let the OS handle it instead. I'll go about fixing that bug and hopefully it doesn't regress for you.

I'm surprised you're seeing glitching with 100ms buffers too; should be plenty of time to provide the next 100ms of audio since we typically run at ~10, 20ms of data.

Marking RBS for the Bluetooth issue which will be new in M62 from  issue 747541 ,

https://chromium-review.googlesource.com/c/chromium/src/+/695701

Actually I need to test this some more before landing, we should already be doing this here:

https://cs.chromium.org/chromium/src/content/renderer/media/audio_renderer_mixer_manager.cc?l=45

I think this is working as expected too since you note that Nougat has 192 frames. Seems we may want to change our code to instead use a multiple of the requested buffer size.

Yes, 4800.  I can screenshot it if you'd like.

This turns out to be PROPERTY_OUTPUT_FRAMES_PER_BUFFER (960) * 5 on this particular platform (Z5 Lollipop MR1).  However, I'm not sure where it's coming up with that multiplier, because when I check media-internals on Chrome Stable running on other Lollipop MR1 devices, I get some wildly different results:

Nexus 4: PROPERTY_OUTPUT_FRAMES_PER_BUFFER is 240!  On Stable, media-internals controller shows 1024 frames_per_buffer (not divisible) and the stream itself shows 240!

Moto G 2013 GPe: PROPERTY_OUTPUT_FRAMES_PER_BUFFER is 1920, and this device can do native 44.1kHz.  On Stable, media-internals shows 3840 frames_per_buffer for both the controller and the stream, which is PROPERTY_OUTPUT_FRAMES_PER_BUFFER * 2.

...and on both of these devices, I can reproduce pops and clicks at about the same rate (they seem to behave identically despite the wildly different optimal settings advertised by the platform and the wildly different choices the Chrome media pipeline made, presumably based on what the APIs returned from the platform/HAL, whereas the Z5 on Lollipop is still way more sensitive in practice).

Here's an interesting little extra nugget: I had said previously that if I plug in a USB DAC on the Z5, I can still reproduce pops and clicks.  But I had been testing a DAC which was also only capable of 48kHz.  I happened to plug a DAC capable of 96kHz into the Lollipop Z5 last night, and lo and behold: absolutely no pops, and I tried really hard!  With that DAC plugged in, Chrome ended up choosing frames_per_buffer of 7680!

Regarding the fact that I see this problem even with seemingly large buffers being chosen, I again draw your attention to the interesting thread at https://groups.google.com/d/topic/android-ndk/HP1n8fphSs0/discussion where the developer was fighting an issue where CPU load on the system could cause his app's playback to produce pops and clicks, regardless of how big or small he made his playback buffer.  His conclusion was that his buffer queueing callback function was not being serviced by the system in a timely manner for unknown reasons...as the size of his playback buffer grew, the system would delay calling back his function even more.  I don't know enough about the Android audio framework or these APIs to know whether he was all wet or not (or even if I'm reading this correctly), but from my largely-ignorant vantage point, the parallels between his issue and this one are striking.

Clearly, though, you're doing something different enough now in Canary when you detect Android API level 25 that pops seem to be eliminated for me entirely.

I suspect that's similar to the issue you're facing. The API 25+ feature lets us opt into a less aggressive playback path; i.e., larger buffer sizes that result in much longer periods. It should be in the next chrome stable release.

The question is how do other audio-playing apps degrade gracefully to lower API levels without facing this problem?  I can Spotify, Play Music, or -- hell -- even ES File Explorer's built-in Media Player all day long without issue on older versions of the OS.

Unfortunately not much we can do here given Chrome's multi-process architecture; switching back to MediaPlayer is not an option for a huge number of security and feature reasons. The reasons this worked previously is Android handled all decoding (bad for security, reliability, web features) and networking.

:-(

That's bad news for anybody who uses an Android device that is stuck on 7.0 or older.  Fortunately, that doesn't include my Z5, but it includes plenty of others.  7.0 isn't exactly old in "Android years".

In comment #12 (Sep. 25) you said you were going to reach out to the Android audio devs about what might be done with older Android versions.  I take it that discussion didn't result in anything useful or actionable?

Thanks for the engagement over the last few months, in any case!