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