[media3-1.1.0] Creation of multiple tracks in audioflinger while seeking

[MrBoe]

Hi together,

We are currently facing some issue during seeking via FFW/FBW and seeking via touching the seekbar:

At some point while seeking often and fast enough within 1 Song the audio tracks won't be released properly and the active tracks within audioflinger grow fast towards the 40 active tracks (which is the cap in our used aosp audioflinger version) and then an InitializationException will be rised.

We found out that the additional creation of the audio tracks is favored by the flushing of audiosink within the "MediaCodecAudioRenderer:onPositionReset" event, where the audiotrack in DefaultAudioSink is temporary set to null. We also saw there the case distincion between "audiosink.flush()" and "audiosink.experimentalFlushWithoutAudioTrackRelease()" (see snippet below), which seems to be gone at later media3 versions. By activating this experimental flush our problem seems to be gone. Unfortunally we currently have to keep the version 1.1.0 and at least we want to know a few things:

1.) Is this a known problem since you decided to temporary introduce the experimental approach? Is there already some releated ticket or some additional information? 2.) The experimental approach seems to work stable. Are there any risks or recommendations while using this? 3.) Is there something we can do within our app for supporting the proper release of the tracks while seeking within a single song if we want keep using the regular "audiosink.flush()"?

  @Override
  protected void onPositionReset(long positionUs, boolean joining) throws ExoPlaybackException {
    super.onPositionReset(positionUs, joining);
    if (experimentalKeepAudioTrackOnSeek) {
      audioSink.experimentalFlushWithoutAudioTrackRelease();
    } else {
      audioSink.flush();
    }

    currentPositionUs = positionUs;
    allowFirstBufferPositionDiscontinuity = true;
    allowPositionDiscontinuity = true;
  }

Kind regards

[icbaker]

I tried seeking back and forth using the 'forward 15s' and 'back 5s' buttons in the demo app (built from the tip of the main branch) when playing the Progressive > Google Play (MP3) sample. I did this quite a lot, and never saw an InitializationException - playback seemed to continue working fine.

Please could you clarify the repro steps for the issue you observe? Are you able to reproduce using the demo app?

[MrBoe]

Hi! I was also just able to reproduce the issue within the demo app. But we speak about the media3 version 1.1.0 and therefore also about the demo app of same version - just to ensure ;) I attached the loggings of "androidx.media3.demo" while reproducing within "Google Play (MP3)" sample: demo_app_1.1.0_issue.txt. I only used the +- seek buttons for reproducing.

Here is also some example output of the audioflinger while the amount of tracks in audioflinger are increasing:

[icbaker]

was also just able to reproduce the issue within the demo app. But we speak about the media3 version 1.1.0 and therefore also about the demo app of same version

When this comment was made the latest stable version of the library was 1.3.1: https://github.com/androidx/media/releases/tag/1.3.1

It's now 1.4.1: https://github.com/androidx/media/releases/tag/1.4.1

Just to check: Are you able to reproduce the issue at the latest version? Ideally built from the main branch, or the 1.5.0-alpha01 tag.

[google-oss-bot]

Hey @MrBoe. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. 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.

@MrBoe 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.