Audio messages are scanned after selecting chat window and slowing down the app

[KPKoch]

Steps to reproduce

1. Where are you starting? What can you see?
2. What do you click?
3. More steps…

If select a contact with many audio messages in the chat. Sadly this happens everytime you switch to the chat.

Outcome

What did you expect?

I expect normal performance. So the wave forms may be analyzed ONE time. And as I really don't care how the audio wave looks like, a toogle to switch this scan of would be great!

What happened instead?

The audio messages are scanned, so the waveform can be displayed(?). This decreases performance on my u8550 so the app is unusable for a little while. Scrolling an with the the loading of new audio messages increases this problem and leads to stuttering scrolling or short stalling of the app, e.g. switching to another contact is delayed..

Operating system

No response

Browser information

latest chromium , firefox, doesn't matter

URL for webapp

Element 1.9.4

Application version

Element 1.9.4

Homeserver

No response

Will you send logs?

No

[Friskygote]

This issue has impacted my experience in using Element many times now. When multiple audio messages are sent (usually not even voice messages but music files), generating waveforms and its parent function often take 1-3 seconds per file according to profiler. This often completely halts usage of the application for quite some time (depending on amount of files to process (and their size?), sometimes even up to a minute when someone shares multiple such files).

I feel like some kind of fallback audio object should be used while waveforms are generated (if possible in the background without killing the UI?) or at least some kind of method to completely stop the process of generating those if performance impact is possible. Perhaps even worth another issue of its own.

Issue should be easily reproducible by sending multiple audio files with size 4MB+ in a channel, switching from the channel and then back to it.

Additionally, it causes a lot of RAM usage, which makes this issue even more worrying because it can be used to DoS systems.

[juanfra684]

I've an encrypted room with a few tens of podcasts and I can't open that room with Element because it always crashes. The only matrix client which works as expected for that room is Nheko.

Please, add an option to disable the auto-download and processing of the audio files.

[masterflitzer]

without killing the UI

yes imo blocking the UI is a no go, this should be done in the background (also performance is much more important than these waveforms, whatsapp e.g. has a much smaller waveform which i don't mind but there is never a UI lag even when audio is loading)

also for me it just loads the currently visible audio messages, so when i scroll a bit up it hangs again and again when i try to scroll a bit (if you have a chat with audio messages regularly)

i'd appreciate if waveforms would be disabled until someone found a fix, then they could be brought back

[masterflitzer]

i think mentioning high cpu in the title of this issue and closing the duplicate would make sense

[t3chguy]

high cpu vs slowing down depends on very many factors

[masterflitzer]

yes but it's important keyword which helps to locate this issue, the now closed duplicate was probably only created because searching for high cpu didn't return any results

[t3chguy]

github keywords can exist in the comments too, not just the title

[masterflitzer]

yes you're right github is smart

[eTomte]

I'd say that this issue has been going on since almost the beginning of the voice messages feature. It doesn't even take very many messages in the chat before things start to slow down noticeably.

[Utesgui]

This Issue is becoming one of the most frustrating things to me. I have multiple people who love to send voicemessages (don't ask me why) and i am now on the point where i can't switch between chats for 20 Seconds or so because the client is processing. I would highly appreciate if there would be some kind of fix for that some time in the future. Or maybe simply an option to disable the waveform generation in general? waveforms are surely nice to have, but if i need to decide between usabillity and waveforms, i would choose usability. This is really bothering me. Thanks to all contributors who make element a great messanger!

[a-mnich]

I agree with the previous speaker.
Based on my experience, many people send voice messages because they don't have time to type a message at this exact moment. Having to wait until a chat is usable is not helpful in that case.
For me, this bug also makes some of my chats almost completely unusable.
However, good usability is important to ensure the everyday practicality of Element and also to be able to convince other people of it.
A solution would be very welcome. Thanks for your engagement.