Slowplayback due to Audio discontinuity

[avsbrowncoats]

[REQUIRED] Issue description

The issue causes slow playback when the user tries to pause and play music a couple of times. It is consistently reproducible on Android Q devices.

[REQUIRED] Reproduction steps

Playing and pausing a couple of times causes the issue. It is recoverable as soon as you hit pause again or next/previous etc.

[REQUIRED] A full bug report captured from the device

Will email the bug report once issue is created.

[REQUIRED] Version of ExoPlayer being used

2.8.4
Also, tried with older versions of exoplayer.
2.5.4 and 2.3.1 and issue is still reproducible.

[REQUIRED] Device(s) and version(s) of Android being used

Pixel 3 XL: It is consistently reproducible on Q. The frequency is less on lower versions of Android

[AquilesCanta]

Please provide complete information as requested in the issue template. The issue template can be found here. If you're unable to share bug reports or test content publicly, please send them to dev.exoplayer@gmail.com using a subject in the format "Issue #1234", where "#1234" should be replaced with your issue number. Please also update this issue to indicate you’ve done this.

[tobint]

@AquilesCanta How can I help improve the actionability of this bug? I want to make sure you have all you need to make this bug useful for you.

[avsbrowncoats]

@AquilesCanta The logs have already been provided to you by email. Let me know what else are you looking for.

[AquilesCanta]

The things we need are actually available in your own post. In this specific case I can't do anything without the media sample.

[tobint]

I'm working with our team to get you access to media. Due to licensing, I'm wondering how we can safely share this media. Is there a standard form / method you use for this?

[AquilesCanta]

I'll paste from above:

[REQUIRED] Link to test content
Provide a JSON snippet for the demo app’s media.exolist.json file, or a link to
media that reproduces the issue. If you don't wish to post it publicly, please
submit the issue, then email the link to dev.exoplayer@gmail.com using a subject
in the format "Issue #1234", where "#1234" should be replaced with your issue
number. Provide all the metadata we'd need to play the content like drm license
urls or similar. If the content is accessible only in certain countries or
regions, please say so.

[tobint]

A member from our team is working on getting you access to a stream.

I believe others are reporting similar issues. Looks like #6475 is the same or similar.

[google-oss-bot]

Hey @avsbrowncoats. We need more information to resolve this issue but there hasn't been an update in 14 days. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@avsbrowncoats if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.

[wallyho]

HI we do have a stream that we can send you. I would like to reopen this issue.

[ojw28]

Please send the stream as requested, and ping this issue after it's sent. Thanks.

[wallyho]

Hi, We tried the HLS streams we were giving and they did not repro the issue. We are asking Amazon music to get us a stream so we can send you.

[wallyho]

Thanks Oliver, we know we made some changes to the amazon version of exoplayer but very small changes. We will do some deep digging to see if we did anything wrong. Do you have any advice upfront? Thanks!

[ojw28]

Do you have any advice upfront? Thanks!

Try and reproduce the issue with the ExoPlayer demo app. That's a very fast way to determine whether you introduced the issue or whether the issue is in the ExoPlayer library itself.

[google-oss-bot]

Hey @avsbrowncoats. We need more information to resolve this issue but there hasn't been an update in 14 days. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@avsbrowncoats if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.

[GingerNinja23]

Hi Oliver. Thanks for your support on this, we really appreciate it. After a bit of investigation we found out that the issue occurs on Pixel phones only when we check for isCurrentWindowSeekable() before attempting to seek into the stream. After adding this check, we are able to reproduce this issue in the Exoplayer demo app as well. I've pushed my demo app changes to a branch here in my fork, could you please look into the issue? Thanks!

[GingerNinja23]

I've been testing this with a Pixel 2 with a repro rate of 9/10, but you should be able to repro this with any Pixel phone I think.

[ojw28]

Thanks for the reproduction steps and demo app! I think this was a platform bug [Internal ref: b/141097367] that got fixed in this commit. I tried flashing my device to internal builds either side of the commit, and confirmed that the issue was reproducible before and not after.

I will leave this open to track coming up with a suitable workaround in ExoPlayer for affected devices.

[GingerNinja23]

@ojw28 Awesome, thanks for spending the time to root cause the issue! Do you think it is safe for us to directly call this seekTo API without checking if isCurrentWindowSeekable() is true? What would happen if we attempt to use this API on a non-seekable stream? It doesn't seem to be throwing any checked exceptions, but could it result in a runtime exception?

[GingerNinja23]

Also, do you know what the target Android release for the platform fix is? Thanks!

[ojw28]

The root cause is triggered when the audio decoder is flushed (this happens when a seek is performed) shortly after being configured. I don't think the issue is necessary Pixel specific. It may affect other devices running Android 10 (but probably not all of them). My understanding is that a fix will also roll out as part of a future Android 10 update, but don't quote me on that!

We should be able to detect the problematic case and instantiate a new decoder instance as a workaround for this issue. I need to find out from the platform team how I should target this workaround. The brute force version would be to make MediaCodecRenderer.codecNeedsFlushWorkaround return true on Android 10 if this instanceof MediaCodecAudioRenderer (you can try this and the problem should go away). It should be possible to target it a lot more precisely than this, however.

[ojw28]

@wallyho @GingerNinja23 - Would it be possible for you to provide an updated link to stream that still works? We need this to make sure our workaround does indeed resolve the problem.

[GingerNinja23]

@ojw28 Sure, I'll get back to you with the updated link to the stream.

[GingerNinja23]

@ojw28 Here you go - https://d29r7idq0wxsiz.cloudfront.net/DigitalMusicDeliveryService/HPS.m3u8?m=m&dmid=203888005&c=cf&f=ts&t=10&bl=48k128k&s=true&e1=1595035600000&e2=1595035600000&v=V2&n=VSQOMQQIAZ4O6&h=80bac0058955f9a3f72efb53727bd9fb885563ed4b25912aab6cdc49b5bcf461

[ojw28]

A workaround is submitted in dev-v2.