Add variable playback speed feature for voice messages

[Medformatik]

Content

Add playback speed control for voice messages with support for 0.5×, 1×, 1.5×, and 2× playback speeds. The speed button is displayed above the timestamp and cycles through the available speeds when tapped.

Motivation and context

Allows users to adjust voice message playback speed for improved accessibility and user experience. This is a common feature in messaging apps that helps users consume voice content more efficiently.

Screenshots / GIFs

Before	After

Tests

Manual testing:

• Step 1: Record or receive a voice message in a conversation
• Step 2: Tap the play button to start playback
• Step 3: Tap the playback speed button (displays "1×" by default) to cycle through speeds
• Step 4: Verify playback speed changes accordingly: 1× → 1.5× → 2× → 0.5× → 1×
• Step 5: Verify the speed setting is applied immediately to currently playing voice messages

Tested devices

• Physical
• Emulator
• OS version(s): Android 16

Checklist

• Changes have been tested on an Android device or Android emulator with API 24
• UI change has been tested on both light and dark themes
• Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request title will be used in the release note, it clearly define what will change for the user
• Pull request includes screenshots or videos if containing UI changes
• You've made a self review of your PR

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

• Your branch should be based on origin/develop, at least when it was created.
• The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
• The test pass locally running ./gradlew test.
• The code quality check suite pass locally running ./gradlew runQualityChecks.
• If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.

[ema987]

Hey! 👋 I was about to submit a PR for this same feature because I didn't notice this at first look, and then just saw yours: nice work!

We ended up making very similar changes. You can see my version in this branch and this commit.

In my implementation, I positioned the playback speed control at the end of the row (similar to WhatsApp) and used an enum to define the possible speeds.

Most of the other changes are basically the same, which seems like a good sign that we’re on the right track!

Since there aren’t clear design guidelines for this yet, I wasn’t sure which layout the maintainers would prefer.
It’d be great to get some direction so we can finalize the implementation and close the related issue.
I would love to have this feature in production! 🎯

[Medformatik]

Hey, thanks for your contribution to this. I'm glad that our implementations are similar. You're right about the design, the maintainers will have to comment on that. I have taken my inspiration from Signal. My design has the advantage over yours that no space is taken away from the waveform. On the other hand, the button is much smaller.

[ema987]

Yeah, I agree with what you are saying. At this point, it's honestly a matter of preference and a design decision to follow current practices, because both solutions work.
We just need to wait for an input from the maintainers.

[bmarty]

Thanks for the PR, technically correct!
Hello @amshakal , we need some design / UX input for the feature. Can you read the comments above and provide feedback please?
CC @mxandreas

[mxandreas]

Thanks for the contributions!

I find the version with the speed button on the right a bit more "accessible" - because the button is bigger and it is further away from the play button. The small downside is that it shortens the waveform so scrolling is probably a bit less precise.

@amshakal wdyt?