Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Multiple Audio tracks (old ones are not closing) in web and client #19294

Closed
YourSandwich opened this issue Oct 5, 2021 · 28 comments
Closed

Multiple Audio tracks (old ones are not closing) in web and client #19294

YourSandwich opened this issue Oct 5, 2021 · 28 comments
Labels
A-VoIP O-Occasional Affects or can be seen by some users regularly or most users rarely Privacy S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Needs-Investigation

Comments

@YourSandwich
Copy link

YourSandwich commented Oct 5, 2021 •
edited
Loading

Steps to reproduce

Running Arch Linux kernel 5.14.9
DE: KDE Plasma
Sound: pipewire.

  1. Launch Element in web or in native client.
  2. Take a call. -> in Sound Manager applications new Chromium pipes appear.
  3. Close the call -> The Tracks are still here.
  4. Take a call again and even more tracks open.

Outcome

What did you expect?

A call opens 1 or 2 tracks maybe an option for selection channel count.
After call closes the tracks disconnect/close

What happened instead?

Element opens multiple tracks and dont close them afterwards

Operating system

Linux

Browser information

Chromium: 94.0.4606.61

URL for webapp

1.8.5-1

Homeserver

matrix.archgang.xyz

Will you send logs?

Yes
@YourSandwich YourSandwich changed the title Multiple Audio tracks on Linux (old ones are not closing) in web and client Multiple Audio tracks (old ones are not closing) in web and client Oct 5, 2021
@SimonBrandner SimonBrandner added A-VoIP O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist labels Oct 6, 2021
@germain-gg
Copy link
Contributor

Adding privacy as this could be interpreted the wrong way and some users might assume malicious intentions here

@SimonBrandner
Copy link
Contributor

So I think we aren't correctly stopping the audio elements, I don't seem to be able to repro with Jitsi

@SimonBrandner
Copy link
Contributor

So, I think I managed to get the AudioFeeds behaving (no idea how) but we still have some 6 audio elements which never get unmounted and they are never paused (those are for notifs, ringing and stuff like that)

@SimonBrandner
Copy link
Contributor

So, I think I managed to get the AudioFeeds behaving (no idea how) but we still have some 6 audio elements which never get unmounted and they are never paused (those are for notifs, ringing and stuff like that)

Apparently, my changes had no effect and this was the behavior before them? Though, Electron seems to be doing something different

@SimonBrandner
Copy link
Contributor

Though, Electron seems to be doing something different

I can find only 6 audio elements though my audio mixer is showing way more than that 🤔

@YourSandwich
Copy link
Author

Though, Electron seems to be doing something different

I can find only 6 audio elements though my audio mixer is showing way more than that thinking

Tell me if i can support you somehow.

@SimonBrandner
Copy link
Contributor

Though, Electron seems to be doing something different

I can find only 6 audio elements though my audio mixer is showing way more than that thinking

Tell me if i can support you somehow.

I don't think we need help atm, since we have a clear reproduction case

@SimonBrandner
Copy link
Contributor

@robertlong has suggested this could be caused by us not stopping the tracks correctly, though as far as I can tell, the bits of code that stop tracks look ok

@SimonBrandner SimonBrandner mentioned this issue Jan 14, 2022
Closed
@YourSandwich YourSandwich mentioned this issue Mar 1, 2022
Closed
@phoxmeh
Copy link

phoxmeh commented Mar 2, 2022

I have been experiencing this myself for the past few months with all recent updates and it seems to get to a point where if I've had a few calls in the day pulse refuses to let any new applications create a new track until I completely kill Element to release all the tracks.

@YourSandwich
Copy link
Author

Same, thats supper anoying espaccialy if you are working with audio and channel wirering.

I found out this issue does not exist on Firefox. But i can only use Jitsi for calles in firefox and no encryption possible in VoIP

@SimonBrandner
Copy link
Contributor

SimonBrandner commented Mar 3, 2022 •
edited
Loading

I have been experiencing this myself for the past few months with all recent updates and it seems to get to a point where if I've had a few calls in the day pulse refuses to let any new applications create a new track until I completely kill Element to release all the tracks.

I can confirm this; therefore, I am going to raise this to S-Major

@SimonBrandner SimonBrandner added S-Major Severely degrades major functionality or product features, with no satisfactory workaround and removed S-Minor Impairs non-critical functionality or suitable workarounds exist labels Mar 3, 2022
@SimonBrandner SimonBrandner mentioned this issue Mar 10, 2022
Closed
@turt2live
Copy link
Member

turt2live commented May 17, 2022 •
edited
Loading

fwiw, this is normal for Firefox if you leave it open long enough on Windows with the Audio Mixer also open. Closing the mixer and reopening fixes it on Windows - does something similar happen to also fix it here?

@SimonBrandner
Copy link
Contributor

fwiw, this is normal for Firefox if you leave it open long enough on Windows with the Audio Mixer also open. Closing the mixer and reopening fixes it on Windows - does something similar happen to also fix it here?

Nope, on Linux at least the only way to get rid of the tracks is to kill Element

@YourSandwich
Copy link
Author

YourSandwich commented May 17, 2022 •
edited
Loading

On Firefox(on linux with pipewire) i don't have this bug somehow. So i imagine this has something to do with the Chromium engine.

@SimonBrandner SimonBrandner mentioned this issue Jun 3, 2022
Closed
@robintown
Copy link
Member

@turt2live theorizes that this could have the same underlying cause as element-hq/element-call#267 (that we're cloning MediaStreams for Safari support)

@lukas-lang
Copy link

lukas-lang commented Aug 6, 2022 •
edited
Loading

I'm pretty sure I am experiencing the same issue on Windows. For me, this causes issues with my headphones: The headphones can connect to multiple devices at once, but will only play audio from one. Since the audio is not properly stopped after a voice call, I have to kill Element to "free up" the headphones & get them to play audio from other devices again.

@SimonBrandner
Copy link
Contributor

I do have a hypothesis that this was fixed in Element Call somehow though I have to give it a proper test somehow

@YourSandwich
Copy link
Author

But element call is using WebRTC and element is unsing the chromium engine. Atleast thats what i understand. Maybe thats an bug with the chromium engine itself?

@The-EDev
Copy link

The-EDev commented Aug 8, 2022

But element call is using WebRTC and element is unsing the chromium engine. Atleast thats what i understand. Maybe thats an bug with the chromium engine itself?

wouldn't this mean many other web and electron apps would've suffered as a result? So far I've only seen this issue in Element..

@SimonBrandner
Copy link
Contributor

But element call is using WebRTC and element is unsing the chromium engine. Atleast thats what i understand. Maybe thats an bug with the chromium engine itself?

They are both using WebRTC. Element uses Chromium engine if you're either using a Chromium browser or Element Desktop (Electron), so the issue probably isn't related to Chromium

@YourSandwich
Copy link
Author

Jup but the issue is not existent on firefox for example. So if you mean that WebRTC is used on firefox then it should have something to do with chomium? or am i wrong here?

@YourSandwich
Copy link
Author

I dont know, maybe its not only chromium itself but its implementation. And discord for example uses WebRTC on Destop leint and in all browsers.

MS Teams uses chromium engine and does not have that issue.

@SimonBrandner
Copy link
Contributor

Could probably be influenced by Chromium but other Chromium apps don't have this issue, so it seems this is also influenced by our own code

This was referenced Feb 17, 2023
Open
Open
@Krafting
Copy link

Krafting commented Mar 7, 2023

Can confirm this on Fedora 37. Also, wouldn't it be possible to replace the "Chromium" text and logo to reflects Element branding instead too ?

@YourSandwich
Copy link
Author

Issue is fixed on ArchLinux and latest Nightly Element build!!!

@t3chguy
Copy link
Member

t3chguy commented Mar 16, 2023

@YourSandwich do you want to close your own issue then?

@SimonBrandner
Copy link
Contributor

Ah, yeah, it seems fixed on my side as well - closing

Let us know if you ever see this again

@YourSandwich
Copy link
Author

Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-VoIP O-Occasional Affects or can be seen by some users regularly or most users rarely Privacy S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Needs-Investigation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@phoxmeh @germain-gg @turt2live @t3chguy @YourSandwich @SimonBrandner @lukas-lang @Krafting @robintown @The-EDev