Element needs an audio player.

[DanHakimi]

Whenever I find an audio file, I need to decrypt it and load it in VLC. This is clunky, particularly when compared to the experience in apps like whatsapp that have an inline audio player with a pause button and seek bar. On web, I open it in VLC, and then VLC closes as soon as the file is playing, so I need to click and go through the open-in process again to listen to a short message twice, or else proactively seek before a message ends to listen to part of it twice. On mobile -- where this is also a problem -- VLC opens in the background, so I have no real way to pause or seek the audio message, which is even more annoying.

We should place a sleek inline audio player with a pause button and seek bar in app on both web and mobile. In WhatsApp, a photo of the speaker appears directly to the right of this audio player, enhancing the experience that the speaker is the person speaking -- that may usually be obvious, but this takes us one step closer to face-to-face conversation.

As a comparison: imagine if images did not show inline, and only opened in a separate app, and only momentarily. That would be absurdly annoying, to the point where Element would be unable to retain users. The experience for users who heavily use audio messages is that annoying. Particularly for vision-impaired users, who may prefer to send audio messages through a conversation.

There is a related proposal here for an in-app audio recording button: #1358. I support that proposal as well, except for the ridiculous and offensive notion that audio should auto-play by default. However, I think this suggestion is distinct, and maybe even more urgent.

[t3chguy]

Bundling an audio player in a webapp is an awful idea, especially when trying to keep the bundle size small and foss, your browser presents one and the app tries to use it. As for seeking not working, that is a Synapse bug: matrix-org/synapse#4780

[t3chguy]

What file format are you trying?

Common ones work for me, OGG not working is a known Firefox bug with it claiming that an OGG (audio only) file is of type video/ogg but then failing to thumbnail so thus being treated as an invalid video file falling back to a plain file.

#7370

[DanHakimi]

.m4a files are the ones we send around. Both the default Apple voice recorder and the Free android voice recorder I use record in .m4a by default.

I'm not sure why you suggest this is an "awful idea" -- many other messengers have the feature, and many users enjoy it. I'm not suggesting that we rewrite the audio codecs firefox already supports, or anything -- simply to add common file types and polish the UI.

I'm a firefox user, and while having the default audio player available for .m4a would be better than nothing, it is not a great UI for these purposes. The seek bar is very short, the volume bar takes up a disproportionately large amount of space, and it lacks the design sensibility of Whatsapp and others (I do like the inline profile photos).

[t3chguy]

many other messengers have the feature, and many users enjoy it.

They just use the browser's media playing capabilities, I very much doubt they ship their own code to decode audio and play it.

WhatsApp's player for example ^ (lack thereof...)

Can you share screenshots of examples in the web?

M4A sending from Element Web/Desktop definitely works fine, it sounds like whomever is sending the M4A files is sending them as m.file instead of m.audio - get them to send a bug report to whatever client they use.

[DanHakimi]

They use Element for iOS. I use element for Android.

Messages sent via Whatsapp's voice recorder play in a dedicated player. Telegram's as well. I'm not able to collect screenshots at the moment, unfortunately.

[t3chguy]

Okay well sounds like your bug is with Element iOS which seems to be sending M4A files wrong, as m.file and should instead be m.audio which will make Element Web&Desktop show an inline player. If you want the inline player to be custom/not Firefox's own I suggest opening a distinct issue for that as that is quite a niche ask.

[DanHakimi]

I don't think that is a niche ask. I think everybody who exchanges voice notes expects a decent player on messages from and to all platforms.

[t3chguy]

Changed this issue into that for you

[t3chguy]

(my downvote is because native is always best for people with different accessibility needs)

[t3chguy]

Element needs an audio player.

As shown in my screenshots, Element Web&Desktop (which this repo is for) has an audio player.

[DanHakimi]

I don't see any issue with my original title, thank you for the insults. Element needs an audio player, as in one of its own, as almost every single application on the remainder of the internet uses. use of the browser's default audio player is rare for a reason -- because it is ugly and drives users away. An audio player would not need to function differently from this default audio player. Please stop attacking my suggestion because you do not understand it.

[t3chguy]

An audio player would not need to function differently from this default audio player.

As soon as you style it using your own icons/elements/style you run into the issue that a user with poor eyesight's accessibility technology software which customised their Audio controls in a specific way to aid with their disability no longer works as they expect and they cannot use the software.

I think the current title is a poor representation of what it means and as part of triage it should be updated to be more clear without having to read the entire blurb.

[DanHakimi]

As soon as you style it using your own icons/elements/style you run into the issue that a user with poor eyesight's accessibility technology software which customised their Audio controls in a specific way to aid with their disability no longer works as they expect and they cannot use the software.

You could make this argument about any ui elements at all. The simplest thing for a screen reader to process is plain text, right?

In fact, my blind cousin is not only capable of processing voice notes on whatsapp, she tends to prefer them. She finds them through screen readers without issue. She wants to interact with them, and that requires other users to use them as well. And that requires a decent UI, friendly to all users -- not just whatever the browser happens to ship with.

[t3chguy]

Yes, once you get to screen readers things resolve again, but users relying on visual accessibility adjustment technologies like contrast, enlarging, the same won't apply.

[hex-m]

I have the feeling you may be misunderstanding each other. Maybe a third voice can help.

Whenever I find an audio file, I need to decrypt it and load it in VLC.

As the screenshots above show (and I just tested) Element-Web and Element-Desktop are able to play audio-files without an external player.

They use Element for iOS. I use element for Android.

For Android there is a highly upvoted issue about this that says:

playing audio files must be integrated into the app that no external other app is required

I don't have an iOS device to test it and couldn't find an issue there. Please create an issue there and point to the related Android issue so people understand what it is about.

Thanks for your engagement.

[DanHakimi]

For Android there is a highly upvoted issue about this that says:

Ah -- I was not able to find this issue using "audio" as a search term, but it seems to be mostly correct.

[hex-m]

Good to hear. In that case I suggest you close this issue.

[DanHakimi]

Good to hear. In that case I suggest you close this issue.

No, my issue still stands. I believe Element should have an audio player. That includes Element web, and does not mean that it should just use the default html5 audio player style built into the browser.

[steef435]

I agree with t3chguy, but I also agree with this:

The seek bar is very short, the volume bar takes up a disproportionately large amount of space

The audio tag with built-in controls does respect a CSS width attribute (on Firefox at least), so maybe this can be addressed, without adding bloat or reducing accessibility? At least something you could play around with I think @DanHakimi.

[DanHakimi]

Yeah, I'm not saying we should re-engineer it or anything, but it can be styled with CSS, which shouldn't break anything.

I'm an attorney, but I might be able to take a whack at it in a few weeks.

[Half-Shot]

This feels largely like a duplicate of #1377, although given the discussion here it might be worth closing that one.

[yajo]

Ain't this fixed already?

[SimonBrandner]

@DanHakimi, do you feel like this issue has been resolved with the new audio player?

[DanHakimi]

Oh, yes, thank you! I didn't realize it was on me to declare it resolved, but... Yes! Is there a button I need to press or soemthing?

[SimonBrandner]

Oh, yes, thank you! I didn't realize it was on me to declare it resolved, but... Yes! Is there a button I need to press or something?

🎉 you did just the right thing :)