You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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()"?
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?
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:
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
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()"?
Kind regards
The text was updated successfully, but these errors were encountered: