Avoid audible glitch when clipping and re-concatenating a single audio source

It works perfect when play a single .m4a file with ProgressiveMediaSource. But it seems not sealmess when play the same audio file with ClippingMediaSource and ConcatenatingMediaSource. For example

        val durations = longArrayOf(20100, 467, 11233, 7100, 6267, 10300)
        var start = 0L
        val audioFile = File(dir, "sample.m4a")
        val audioSource = DefaultMediaSourceFactory(context)
            .createMediaSource(MediaItem.fromUri(Uri.fromFile(audioFile)))
        val concatAudioSource = ConcatenatingMediaSource(true)
        for (i in 0 until durations.size) {
            val durationUs = durations[i] * 1000
            val end = start + durationUs
            val clipAudio = ClippingMediaSource(audioSource, start, end)
            concatAudioSource.addMediaSource(clipAudio)
            start = end
        }
        _player?.run {
            setMediaSource(concatAudioSource)
            prepare()
        }

then you will heard that an obvious pause(maybe glitch?, I’m not sure) between two period. It’s easy to reproduce

[tonihei]

the reason why produce a glitch

The reason is that ExoPlayer flushes the MediaCodec between the different audio resources. If you disable the flushing manually and keep the same codec instance, everything works smoothly without any audible glitches.

We have to flush the codec in the general case because we can’t know whether feeding data from two audio sources to the same decoder consecutively is save (=doesn’t result in some other form of audible glitch). So this enhancement is tracking to either:

• keep the decoder in some cases where we can be sure it’s safe (unclear if there is such a case)
• signal to the decoder that two consecutive audio sources are continuous and can use the same decoder. This only makes sense in combination with ClippingMediaSource, so needed to be forwarded from this source somehow.
• Support merging sources with different number of periods. This is the most flexible approach as it avoids clipping to start with. It doesn’t fit very well into our media model though.

[YouheiLee]

And I tried that if I cut a resource at an exact pcm frame(I use atds as audio format), there will produce a glitch either. so I guess the reason why produce a glitch is not because ExoPlayer can not cut audio resource at an exact pcm frame but there has no pre-cache of next period when the active period is playing. But I’m not sure about that. I will read source code more deeply when I have time。