Remove 2 minute voice audio limit

[stratacast]

Your use case

What would you like to do?

Have no cap on voice audios. I should be able to start a voice recording and go as long as I want without feeling worried about losing my audio

Why would you like to do it?

Sometimes longer voice audios are necessary. Maybe a conversation that can't be had over phone so someone can listen and respond later. Sometimes voice audios just vanish when you hit the 2 minute mark.

How would you like to achieve it?

Remove the time limit entirely, or have a setting somewhere to enable no limits on voice audio length

Have you considered any alternatives?

Yes. For long audios I use Signal, despite wanting to use Element. I can also record a voice memo from iOS's voice memo app and upload it but that should not be a required step to send a voice audio.

Additional context

Sometimes I will speak with people over voice audio and we will discuss lengthy topics. Currently we are losing voice audios at the 2 minute mark. Sometimes they cut us off, other times (and most often) we lose the audio entirely

[daniellekirkwood]

This is being considered by the team, thanks for your feedback.

For internal folks: https://element-io.atlassian.net/browse/PSF-461
I'm marking this as a Z-Papercut over Z-WTF as it's not an easy fix and therefore outside of the bounds of the WTF project

[jacotec]

That's definitely needed ... and I don't know who thought this limit would be a good idea ...

It's the only platform I know which has at least a limit on voice message lengths

[RevAngel7]

My IOS contact struggles with this as well. Starts, 2 minute limit cuts the message without recognization off, loosing train of thought, trying to recollect... The 2 minute limit hampers communication A LOT.

[bmivzkrp]

I join this request.
Dear developers, please remove this limit, or at least make it one hour long.
Also, I would like to be able to adjust the bitrate of the voice messages, as there are times when the audio quality is not very important, so it is possible to reduce the voice message at the expense of poorer quality.
I would also like to see this extended to the Element app for all operating systems.
Many thanks for your attention to my comment.

[networkException]

If you pay attention to the history of this pull request then you can see commit b9c8358 with an adjusted limit of 15 minutes already implemented since release 1.8.25, as well as various other commits and pull request for android and web / desktop with the same change.

[jakewb-b]

Hi folks!
We're as keen as you all are to increase the limit. As referenced above, we did some experimentation with increasing the limit to 15 mins, as a first step to a longer future limit (my goal is either no limit, or a limit so high that few users will ever hit it) but we ran into a few unexpected issues on mobile that aren't apparent with shorter messages, but pop up as messages get longer. We have a plan to work on this further over the coming months so definitely aren't ignoring the request, or the frustration that the current limit causes.

[bmivzkrp]

Yes, I saw that. But 15 minutes is also not much, so I commented on this issue. 18.08.22 12:54, Jakob-Niklas See пише:

…

If you pay attention to the history of this pull request then you can see commit b9c8358 with an adjusted limit of 15 minutes already implemented since release 1.8.25, as well as various other commits and pull request for android and web / desktop with the same change.

[bmivzkrp]

@jakewb-b I understand. Thank you for your answer. 18.08.22 13:01, jakewb-b пише:

…

Hi folks! We're as keen as you all are to increase the limit. As referenced above, we did some experimentation with increasing the limit to 15 mins, as a first step to a longer future limit (my goal is either no limit, or a limit so high that few users will ever hit it) but we ran into a few unexpected issues on mobile that aren't apparent with shorter messages, but pop up as messages get longer. We have a plan to work on this further over the coming months so definitely aren't ignoring the request, or the frustration that the current limit causes.

[jacotec]

One year later ... any updates regarding this annoying limitation? @jakewb-b

[jakewb-b]

@jacotec I’m afraid not - we’ve still not had an opportunity to make the necessary changes to the underlying implementation, so as to resolve the memory issue with longer messages. My guess at this point is that we will probably only fix this as we re-implement voice messages on Element X.

[RevAngel7]

To be honest, the one who uses voice messages to communicate with me got so frustrated that contact over voice messages dropped off quite heavily. And every second message is like "aaargh, the ***** app killed my message again. So, I try to remember what I was saying the last 2 minutes"... Frustration in the voice, not wanting to communicate over this function any more. Well, from that point of view, this communication app failed, at least from my point of view (communication over IT training experience of 20+ years). So lets face it. I still like the app and since I use it under Linux desktop and android for myself. I like that it runs under a lot of environments without dependencies to a smart phone, but can also be used on smart phone's OS as well. So my workaround was to suggest to my IOS using contact to record a message over his preferred recording app and send it to me via file attachment over element. And I asked myself, why did the devs of this function did not think about that before I did? It would not be hard to rewrite the function, pack the audio into a very common codec with a high working probability under all platforms and then just send it via file attachment and implement a record and play function for these files in the app. I am no tech expert, maybe it is like that already. But why does it still not work and still de-motivates users to communicate over that broken function? Just my two cents, please consider my criticism as constructive.

[Johennes]

[...] pack the audio into a very common codec with a high working probability under all platforms and then just send it via file attachment and implement a record and play function for these files in the app

The technical problem is around the playback UI where you have to analyze the waveform to render its curve. We could certainly implement a file attachment fallback without a playback UI but then again it doesn't feel sensible to put our time into another hack rather than properly fixing the root cause. Doing that in the current apps has been deprioritized for now as we think our time is better spent on https://github.com/vector-im/element-x-ios.

So in a nutshell, we totally acknowledge the problem. We have tried to fix it last year, as you can tell from the PRs linked above. It's not a trivial fix though and so we've deferred this to Element X.

[RevAngel7]

Thank you Johennes for your answer! Since I am only a user, I really appreciate you telling us that, because it involves the kind of strength and honesty I value in people. It's not a defeat if you can learn something through it. (Trying, trying harder, failing, accepting, communicating, learning, moving on.) So thank you again for going through this process to everyone involved!

[jacotec]

@Johennes Is there any roadmap for the Element-X release? Any testflight access planned at some point?

[Johennes]

@jacotec we don't currently have a public roadmap available for it but we're aiming to release a public TestFlight build in the very near future. You should be able to follow the progress, e.g. through https://matrix.org/blog/category/this-week-in-matrix.

[Johennes]

See also element-hq/element-x-ios#428

[jacotec]

@Johennes Coming back to this as RocketChat (again) kicked their users in the a** and I have more pressure moving my folks to Element.

As the X-Releases of the mobile app seems to be still far at the horizon, is there any way to at least slightly improve the limit in the mobile apps? At least 5 or 10 minutes? Any minute would help.

Still I don't understand the issue in general as any other apps are dealing fine with long messages. And in Element I don't have this limitation in web, and the mobile apps playing the long messages recorded from Web.

[Johennes]

In order to increase the limit, we'd need some sort of loading UI as otherwise the UX can get fairly confusing (see also #6543)). We're doubling down on Element X right now so I'm afraid we won't be able to put any further time into this right now. Apologies, we are aware that this limits the usefulness of the feature but we believe it's more worthwhile to concentrate on Element X right now.

That being said, if a community member would manage to make this work with non-invasive changes, we'd certainly appreciate a contribution.

[stratacast]

@Johennes Coming back to this as RocketChat (again) kicked their users in the a** and I have more pressure moving my folks to Element.

As the X-Releases of the mobile app seems to be still far at the horizon, is there any way to at least slightly improve the limit in the mobile apps? At least 5 or 10 minutes? Any minute would help.

Still I don't understand the issue in general as any other apps are dealing fine with long messages. And in Element I don't have this limitation in web, and the mobile apps playing the long messages recorded from Web.

Sorry for the total off topic, but can you point me to what Rocket Chat did?

[jacotec]

Sorry for the total off topic, but can you point me to what Rocket Chat did?

They are constantly removing essential features from the Open Source version over into their Enterprise Edition (Paywall) which starts at €175/month.

First they limited push messages (which can be bypassed by compiling the mobile apps by yourself), then they removed LDAP sync, now they removed message read receipts (basic feature of any messenger).

So, if you want to use it except for a big company which wants to pay for that, my advice is to stay away from this. You'll never be sure which feature they steal next.

https://forums.rocket.chat/t/update-6-0-0-read-receipts-complaint/16164

[stratacast]

Sorry for the total off topic, but can you point me to what Rocket Chat did?

They are constantly removing essential features from the Open Source version over into their Enterprise Edition (Paywall) which starts at €175/month.

First they limited push messages (which can be bypassed by compiling the mobile apps by yourself), then they removed LDAP sync, now they removed message read receipts (basic feature of any messenger).

So, if you want to use it except for a big company which wants to pay for that, my advice is to stay away from this. You'll never be sure which feature they steal next.

https://forums.rocket.chat/t/update-6-0-0-read-receipts-complaint/16164

Good to know, thank you. Our company hasn't used any of those features, so that explains why I don't know about it. I use Element daily for personal use and host my own Matrix server. I often think of what it might look like to move my company to Element/Matrix and away from Rocket. The biggest issue for me has been with E2EE in Matrix. For example, the other day I signed into a browser on a fresh OS install and suddenly I was no longer able to decrypt some messages, even though I did the session verification. I would probably have to disable E2EE for my work, which would be fine on our own server (which is how Rocket is now). Hoping these issues can be ironed out sooner rather than later. I love the ecosystem but I often have to play support for things I probably shouldn't have to

[jacotec]

I've downloaded the Testflight of Element-X which makes me think a working public release with all needed features will likely not happen before mid 2024. It's not even at 20% of Element-IOS. So we really need a solution for this annoying limitation.

In the tests, have there be any length which still works? As we've learnt from @Johennes 15 Minutes had some strange issues ... what about 5 Minutes? Really every minute counts and I'm pretty fed with weekly complaints by my users.

Especially as Element-Desktop, Element-Web and FluffyChat does not have this limit and longer messages recorded by these are working fine playing in Element-IOS. And as the issue is named to be in the playback UI ... no one sees issues in playing back these.

What about doing the playback UI like this instead of rendering the waveform, which makes the trouble:

Better to have a fully working tool than fancy stuff ... just my 2 cents.

Any chance to at least raise the limit to at least 5 minutes with the next release?

[Johennes]

@jacotec raising the limit itself is relatively trivial. Are you able to build and run the app locally to try out if 5m would still be usable?

[jacotec]

@Johennes Yap, I think I can do this, but I can't distribute it to my users ... getting my own app into the app store is quite not easy.

But the test is more easy than building an own app: As you've mentioned the issue is in the wave file analyzer on the receive side, I did around 10 recordings with a bit more than 5 minutes in Element Desktop (which does not have a limit) into a test room. No issues at all with playback all these in Element-IOS 1.10.12 on my iPhone and iPad.

[Johennes]

Trying it out in #7582. It does seem ok-ish to me so far. Waiting for product feedback in the PR.