[macOS] Wire is constantly keeping coreaudiod alive, wasting a huge amount of battery

[rbieb]

There seems to be a bug when handling audio. According to the system monitor, coreaudiod constantly uses around 8% cpu as long as wire is active. Killing wire immediately fixes the problem, reducing the load to 0.

So something seems to be fishy with the way wire handles audio. Would be great if this could be looked into.

[herrmannplatz]

This might be related to not closing the audiocontext that we used for a call. So to clarify, do you had a call?

[rbieb]

I did before, but I just tried to reproduce the issues with another call and that didn't work out.

[gregor]

I have previously looked into this issue. The AudioContext is definitely closed. Seems to be an issue with electron as despite that happening as expected the coreaudio is kept alive.

[max-baz]

Curious, I've just had a call and then saw this issue, I checked on my Linux and pulseaudio process was using around 8% of CPU (after the call). The wire process was using like 30% of CPU, but that we are tracking with #135. I waited a bit, tried to switch conversations, that didn't change anything. I closed the app, and pulseaudio process jumped down to 0% and stays there.

Will try tomorrow to see if this is reproducible every time, but looks like it's not macOS-specific issue.

[max-baz]

I tested quite a number of times, it happens every time, but there is a trick. When two parties call each other, only one of them will have issues with audio daemon afterwards... And it's not who initiated the call that matters, but who pressed the "leave call" button.

Every time, regardless of who called whom, the person that pressed "leave call" will have high CPU usage on the audio daemon process, until they close the browser tab with Wire.

I double checked, the AudioContext is indeed being closed every time. But what is it that is happening only on the side of the person pressing "leave call" button?

[kostadinstoilov]

I can also confirm that I experience this behaviour with the latest version of Wire Desktop on Linux with pulseaudio.

Pulseaudio shows that the application is still 'active'.

It happens after a call, I'm not sure I was the one that pressed the 'leave call' button.

[max-baz]

See #636, now we know that all platforms are affected by this bug: macOS, Linux and Windows.

This bug definitely requires another look 😉

I wonder if someone could verify my finding that the audio is not getting closed only when you are the one who pressed the "leave call" button. Then we could at least be sure where to search for the bug.

[lingfish]

Hi,

I wonder if someone could verify my finding that the audio is not getting closed only when you are the one who pressed the "leave call" button.

Not for me. Even if I just go into prefs and choose my Jabra channel (and only for speaker, not mic), it'll then keep it open.

[max-baz]

Interesting, I certainly don't see this behavior on Linux, tried multiple times and the channel is always released after ~5 seconds after closing "preferences".

I'm wondering now how to debug this, how to see, I don't know, what exactly piece of code is the cause of opened channel, why was it opened and where was it supposed to be closed 🤔

[gregor]

We have intensively looked at this issue before. It seems like the issue is rooted in electron and not the webapp code since the resources are always released when using browsers. But we were never able to pin it down completely. Any input is appreciated.

[max-baz]

I don't think this is electron problem @gregor, I can actually reproduce this in Google Chrome pretty reliably.

I have two laptops in front of me now, doing the following experiment:

• Windows laptop has Wire for Desktop open.
• Linux laptop has Chrome open, with no open tabs. Pulseaudio shows 0 open streams from Chrome.
• I open app.wire.com on Linux and see pulseaudio showing 2 open streams for Chrome.
• After 10 seconds both streams are closed, so 0 streams are open.
• I'm making an audio call from Linux to Windows
  • While the call is ringing, I see two open streams:
    • Stream 1 is making the ringing sound
    • Stream 2 is silent. I change the volume of this second stream, so I can distinguish it in the future.
  • When I accept the call on Windows laptop:
    • Stream 1 is closed.
    • Stream 2 remains in the list, but it's still silent.
    • Stream 3 is opened, and this is the stream used for audio call.
  • When I hang up from the Linux laptop:
    • Stream 2 is closed (the one that was always silent).
    • Stream 3 remains open forever.
    • Stream 4 is briefly opened to make the "hang up" sound and immediately closed.

Whatever I do afterwards with Wire, the stream 3 remains open.

Interesting further facts. I repeat the procedure, and that stream 3 is still used for transferring the audio from the new call! So no new stream is created for a new call, it is getting reused, this I find interesting.

And now to the most fun part. I call the 3rd time, the stream 3 is again reused. But, this time I hang up from the Windows laptop. And guess what, this time the stream 3 is closed! No more hanging streams, CPU usage on Linux drops to 0.

And I can reproduce this exact behavior every time.

Sooooo.... something is definitely different on the "hang up" part, there is some cleanup missing when I'm the one who closed the call.

[gregor]

@maximbaz Thanks for the detailed explanation. I will take yet another look at our stream handling.

[baimafeima]

@maximbaz It's definitely not macOS specific. I am running Wire on Solus, a Linux-based operating system, and pulseaudio is up to 36% when Wire is idle without any active conversations. Wire itself consumes another 20-30%. During the update notification that a new version is available my CPU load was up to 98% while being in a video chat making any further conversation impossible.

[rbieb]

Any news? @gregor

[dbquarrel]

They just closed my report for significant battery drain saying they don't care and marked it resolved.

I'm stunned. What is the point of having bug reports when the developers will just say "ha, no."

It's the most significant issue with this app.

Time to find a replacement. It's probably better to just do bug reports in the App Store reviews along with one star. What a short sighted company this is.