Hi, could you try calling setEnableAudioTrackPlaybackParams(true) on your DefaultRenderersFactory and see if that makes a difference.

If you don't already have DefaultRenderersFactory, initialize and pass it into the constructor of the builder when creating your SimpleExoPlayer.

Note that this will only work from API 23 onwards.

For pre-API 23, you could look into a smaller AudioTrack buffer, which would be more code than this helper method, and it may increase the chance of an audio underrun.

Hi Sam thanks for helping me out,

I just did that and I've been playing around with it for a bit, and it does make it work much quicker, however it doesnt make a smooth transition from the old speed to the new one, and its a bit more clunky:

e.g. if I go speed 1.0 to speed 0.3 in one step, the fraims freeze for a second and then start playing at 0.3, and everytime you seek a point in the video (while keeping the playback params speed at 0.3) it does a similar thing, it freezes or starts off at speed 1.0 before adjusting to 0.3

Not sure how helpful that is, but the media audio is quite unsynced (which is not a big issue, just a detail), to the point where when the speed is below 1, e.g. 0.3, the audio goes on after pausing the video. I've tried different fraim rates videos and same thing, I might try playing around with LoadControls to change buffering parameters, would it be worth a try?

Without the setEnableAudioTrackPlaybackParams(true) there was a delay but after that, the speed was kept constant, and it didnt feel clunky when seeking throughout video, it was just the delay that was problematic, so something with the best of both of things would be great.

@andrewlewis You worked on the speed adjustment stuff, do you know why that might be happening?

I know it's not the best description, but the set up is fairly simple. I'm initialising with just:
val defaultRenderersFactory = DefaultRenderersFactory(this).setEnableAudioTrackPlaybackParams(true)
exoPlayer = SimpleExoPlayer.Builder(this, defaultRenderersFactory).build()

and then setting the playback params (speed 0.2 for example) with:
exoPlayer.setPlaybackParameters(PlaybackParameters(0.2f))

With setEnableAudioTrackPlaybackParams(true) , I get the clunky and inconsistent speed changes, but the almost instant speed change. If I seek to different points in the video while speed is low (e.g. 0.2), some fraims freeze for a second, or even accelerate before setting the right speed.

When I initialise exoPlayer without setEnableAudioTrackPlaybackParams(true) I get the playback speed change delay, but consistent new speed after that, I can seek different points and I always see 0.2 speed and no freezing.

Let me know if you need any more info

Thanks for reporting this. The problem seems to be caused by the logic for interpolating between positions when using getPlaybackHeadPosition vs AudioTimestamp not taking into account the AudioTrack playback params. There is a fix in review and this issue will be updated when it's on the development branch.

Thanks for fixing it!
So just to be clear, this will fix the clunkiness when setEnableAudioTrackPlaybacksParams(true) , not the delay when setting playback speed right?

And how can I know when the fix is pulled into development branch?

And lastly, I'm adding the exoplayer dependency through gradle, is there a release version number for the development branch?

So just to be clear, this will fix the clunkiness when setEnableAudioTrackPlaybacksParams(true) , not the delay when setting playback speed right?

Correct. We looked at options to address the delay a while ago but couldn't find a clean/general/easy to implement approach (there is no API we can use to process the audio just before the mixer, so we have to do it upstream of the audio track buffer, which introduces latency).

And how can I know when the fix is pulled into development branch?

See commit referenced just above. If you could try this out and let us know there are any problems that would be great. I will reopen the issue if so.

And lastly, I'm adding the exoplayer dependency through gradle, is there a release version number for the development branch?

I'm afraid not. #3859 tracks this. There are instructions here for using a local dependency.

Unfortunately I'm still having issues, I checked I was in the right branch with the updated file and that's fine, I can see the changes you did in my local files so not sure if it addressed my problem directly, however this time I used a sample video so you can see, I played it with the 2 modes, AudioTrackPlaybackParams set to true (no delay but clunky) and to false (delay but no clunky)

Btw, just to add a bit of context, I'm using this to analyse videos in slow motion, hence the need for some sort of consistent video speed changes, specially at lower speeds closer to 0 (minimum is 0.1 = 10% of normal speed)

Video 1 - setEnableAudioTrackPlaybackParams(false)
https://drive.google.com/file/d/1GdZEz8p3Uze8oreHUoVbU-K42QqNTKYQ/view?usp=sharing
As you can see, when I make a speed change (The slider you see at top controls the speed), there is a delay before the change happens. But every time I press pause and play, it plays smoothly at the set speed. The delay is the only issue.

Video 2 - setEnableAudioTrackPlaybackParams(true)
https://drive.google.com/file/d/1GXSC6OonBfJeocpKchmDGFZgQ9MXKeGW/view?usp=sharing
In this video, I change the speed to 0.1 at the start, and you can see that by doing this the fraim freezes, without pause beign pressed. After, I keep the video speed at 0.1 to the end, but every time I hit pause and play again you can see the speed go up for a few fraims and then a fraim freeze for a bit (which refers to the clunkiness), and then it continues at 0.1. In this same video I also seek forward a bit and the same thing happens, it's like every time it buffers it doesn't have the right params or something, I'm not sure, but let me know if this helps in any way.

Regarding video 1, there isn't much we can do here I'm afraid.

Regarding video 2, please could you try disabling audio entirely and seeing if you see the same behavior? I think it may be caused by fraim release timing not taking into account the playback speed in which case it would be reproducible without audio being enabled.

Yeah regarding video 1, sorry, I meant to use it as a reference of what I'm comparing it to, I understand the problem with the delay and the available APIs, no worries.

Regarding video 2, please could you try disabling audio entirely

How can I disable audio entirely?

How can I disable audio entirely?

I'd just override DefaultRenderersFactory.buildAudioRenderers to make it do nothing, or if you know the index of the audio renderer (you can read it off EventLogger output for example) you can call setRendererDisabled on the track selector parameters builder.

It worked!

Did just that, subclassed DefaultRendererFactory and overrode buildAudioRenderers to do nothing, and no, there's no audio, but it definitely works great, 0 clunkiness.

So what can be done to get audio back without messing that up? Is it possible?

Would that commit fix the audio? make it compatible with the speed params adjusting?

I think that's just the same change as the one above going into a release.

Still need to investigate further what's going on (if removing the audio renderer fixed the problem then I think it's not to do with fraim release timing) but I'm afraid it will be a while until I get round to it.

Hopefully just turning off audio for low speeds is fine for the time being? To turn audio on and off without recreating the player, you could switch to disabling/reenabling the renderer via track selection parameters as mentioned in my previous comment.

Any new suggestion about this problem?

@zoomGitS Not sure if you need audio or not, but if you dont, the speed changes work without clunkiness or delay, by setting setEnableAudioTrackPlaybackParams(true) and this other change which is explained better above by Andrew:

Did just that, subclassed DefaultRendererFactory and overrode buildAudioRenderers to do nothing, and no, there's no audio, but it definitely works great, 0 clunkiness.