jamulussoftware
Jamulus 3.7 hangs -eventually- on Mac Big Sur
Describe the bug
Jamulus hangs -- pretty much every time -- after a while -- can be 5 minutes, can be an hour, on my Macbook Pro (2020, 2 GHz Intel quad-core I5) running Big Sur 11.2.3. Not a problem with same Jamulus version on an older Mac running an older OS.To Reproduce Join a Jamulus session, then don't touch anything. Eventually I will get a spinning ball and can't activate any Jamulus controls. Sometimes Jamulus continues to function; at other times, the connection drops. (does not happen with current Jamulus on an old Mac running High Sierra.)
Expected behavior
Expected behavior is a normal Jamulus session.Screenshots
Operating system
MacOS 11.2.3Version of Jamulus
Jamulus on this same machine seems to have buffer underruns/overflows -- sound gets glitchy: I can temporarily cure it by re-setting the buffer delay. It seems to be when I don't do reset the buffer delay that the hang occurs.
Hi! Thanks for the report. This sounds very similar to #1643, but I'd like to keep it open for now as the other issue mainly targeted a regression introduced in 3.8.0 (despite the initial report).
We suspect a general problem in the Qt event handling on Mac with recent Qt versions and yet have to find a way to work around it.
It would help if you could try the following:
- 3.8.0rc2 (regular Mac build) - It woud be best if this version did not show any issues for you as it is planned to become the 3.8.0 final release. I suspect that you will encounter the issue with this version as well, but this information would help a lot.
- post-3.8.0rc2 build with Xcode 12.0 (#1794)
- 3.8.0rc2 (legacy Mac build) - I suspect that it will not show the issue, but may have design glitches in the settings window tabs (please confirm).
- 3.6.2 - Unless you had already been running 3.6.2 or earlier without issues, it would be interesting to know if this version still works reliably.
Also @RonCohen1 could you say which skin you are using? Normal, Compact or Fancy? And could you try using a different one to see if it makes any difference?
Hi, I hadn't found issue #1643 on a search before posting my report; it does seem like the same issue. I am trying to figure out how I can usefully contribute to this discussion -- my rehearsals with large numbers of participants are becoming less frequent as pandemic restrictions are lessening. But maybe the following is of use: Last night I had Jamulus running simultaneously on two Mac computers -- one I was using to provide a one-way audio bridge to Zoom using Blackhole as output device on Jamulus and input device on Zoom. That was running on my 2020 MBP running Big Sur, and that's the one that got the spinning beachball, twice -- once when I was first setting up, before the connection to Zoom (but with 4 clients connected to Jamulus), and once after an hour with 20 clients connected. The second Jamulus was running on my 2009 Macbook Pro (running High Sierra), that I was using for my active participation in the rehearsal. On that one, Jamulus ran flawlessly for close to two hours. Same version of Jamulus (3.7.0) on both. The reason for running two instances of Jamulus on two machines: Jamulus on the 2020 MBP has been consistently problemmatic. Particularly with large numbers of clients, I get a build-up of glitchy crackles and pops in the audio that I can temporarily stop by re-clicking on the buffer delay button. I do not have this problem at all on the older Mac. But the older mac is sufficiently under-powered that I can't count on running both Jamulus and Zoom. Hence the two-Mac solution. I note that if I run a Jamulus session on the newer Mac and do the temporary fix of the glitches I mentioned above every few minutes, I can stay in a rehearsal for two hours with no problem -- so the suggestions made in the #1643 discussion about memory leaks and swapping seem to be right on target. I think I did not have the spinning ball problem on 3.6.2. But I can't help but think that the fact that I had had the problem a bunch of times on the newer mac and never on the older one implies a connection between the beachball problem and the glitchy audio problem; I've wondered about that being related to a memory leak. Is that plausible? I think one of the other replies asked about skin, etc: when I'm participating in big groups, I almost always have the compact skin activated. Chat window may be open or closed. Settings window is always open, but may not be in the foreground. As to testing with different versions: this is probably only practical if I can reproduce the problem with only two clients connected, as I'm not having frequent-enough large-group rehearsals to gather sufficient data in a timely way. Ron
@RonCohen1 Thanks for the feedback!
Just a short brain dump of things to play around with, although all of it seems QML-related so might have no effect for us:
https://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html QSG_RENDER_LOOP=threaded vs QSG_RENDER_LOOP=basic.
https://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html#performance
https://bugreports.qt.io/browse/QTBUG-88248 sounds related (event-related leaks), but seems to only occur with Qt 5.14 or newer while our previous builds were based on 5.9, IIRC.
Reopening based on chat agreement that this is not a duplicate of #1643 but somehow related. Issue investigation should continue here.
I have installed the three versions of 3.8rc2 in the post three days ago from Christian Hoffmann hoffie. I have had some limited opportunity today for testing. Most interesting is that for the "post-3.80rc2 build" https://github.com/jamulussoftware/jamulus/suites/2873144701/artifacts/64218065, the top utility shows memory usage that (for me) seems to grow then reset. So it seems that memory is being cleaned up periodically. I have not yet been able to test other versions with a significant number of users connected. I did observe GUI issues with the legacy build, as expected: in the Settings window, I can't read the name of the selected tab.
Hi, did a 3h session with the 3.8 release version of Jamulus on a MacBook Pro 2015, MacOS 11.4 (up to 15 players). As soon as Jamulus is running in the background (Chat and Main window open, Preferences closed) memory usage increases about 3MB per every 5 seconds (visible in MacOS activity monitor). When switching back to Jamulus, Memory usage go’s down again.
Hi, did a 3h session with the 3.8 release version of Jamulus on a MacBook Pro 2015, MacOS 11.4 (up to 15 players). As soon as Jamulus is running in the background (Chat and Main window open, Preferences closed) memory usage increases about 3MB per every 5 seconds (visible in MacOS activity monitor). When switching back to Jamulus, Memory usage go’s down again.
Thanks. I think this is a similar scenario to the one we tried to address by moving the ping stats. Maybe by putting them on the main window we just moved the problem to everyone, rather than only those with the settings window open? :(
What happens if you have the Jamulus main window on top, but not interacting with it?
Hi, i tries this scenario, had Jamulus main window on top all the time, but did not interact and Memory usage climbed from 130MB in the beginning to 450MB after about 1hour and 15 minutes session with three people in total. Trying to interact with Jamulus showed the beach ball for about 5 to 10 seconds and then it was reacting again.
FWIW, I am having this same issue with 3.8rc2 on a recently updated Big Sur mini. The server is started from the command line (not via applications). When jamulus hangs, it takes out the network entirely on the Mini. It is normally (or coincidentally) preceded by a few "Bad Address" errors when trying to register with the CS (Genre2). It might also be worth nothing that the Genre2 CS seems to be acting a bit wonky of late -- even when using explorer.jamulus.io I occasionally get "no data" messages on auto-refresh. All along I thought it was on my end until I stumbled across this thread.
had Jamulus main window on top all the time, but did not interact and Memory usage climbed from 130MB in the beginning to 450MB after about 1hour and 15 minutes
I can't reproduce this on 3.8.1 BigSur 11.6. Memory sits at about 115-120Mb consistently after running for about 45mins. Jamulus remains responsive. Widow mostly in the background. I was the only one on the server most of the time though, and muted.
I still have the issue under MacOS Big Sur latest version and Jamulus 3.8.1. Intel MacBook Pro late 2015.
when Jamulus is not the App with active Window is becomes unresponsive after some minutes of jamming and shows the beach ball for up to 20 Seconds before responding again.
OK I didn't try playing on the connection (I'm on a MacBook Air 2019 BTW). I'll see if I can do that with this Mac (I'm usually on either Linux or Windows)
Tried this while playing the other day for about 45mins. Can't reproduce the issue.
Tried this while playing the other day for about 45mins. Can't reproduce the issue.
I regularly observe it using 3.8.1 on Mojave. It only happens if I have been playing for a long time (e.g. an hour) without touching the computer, and without Jamulus having focus. I have two screens, with Jamulus on one, and Chrome running Jitsi on the other. Typically, the last thing I touched was Chrome, so Jamulus, although visible on the other screen, does not have focus. When much later I go to click on the Disconnect button in Jamulus, I get the spinning beach ball for quite a few seconds before it starts responding again.
I wasn't running any apps other than Jamulus. But then maybe I'd not been playing long enough to see the issue?
I wasn't running any apps other than Jamulus. But then maybe I'd not been playing long enough to see the issue?
I think it only happens when Jamulus does not have focus for an extended period of time.
There is a small chance that moving our builds to Qt6 might help with this issue. If someone wants to try, feel free to download the completely untested Qt6 Mac build from PR #2300. Expect breakage though.
Please post in this issue, if you can still observe the described bug with this build or if things get better or worse. Please post to #2300 if you find any other issues with this build.
Tried it today with latest MacOS 11 version. Still the same issue unfortunately :-(
This seems to be (1) not specific to a MacOS version (has been reported on Mojave, Big Sur, and maybe others) and (2) requires that no Jamulus windows have focus for some time (amount of time varies). I haven't seen any reports for a M1 Mac (all seem to be Intel), but I have an M1 so will see if I can replicate.
Here's another build to try: https://github.com/jamulussoftware/jamulus/suites/5504510055/artifacts/176206626 It's from #2449 which uses a newer Xcode/macOS SDK. Again, there's only a rather small chance that it helps, but it would be helpful to know.
Feedback appreciated!
Another thing to try: Could someone try running export QT_MAC_WANTS_LAYER=1 and starting Jamulus via command line (from the same Terminal)?
(The linked bug report does not match exactly what's reported here. Still, it's also about UI-related hangs starting with Big Sur, so there's at least some chance... And btw, Qt ~5.12.3~ 5.15.3, which was just released, claims to have a fix for exactly the linked issue).
I tried it today in an online session. The bug is still there, but it is much better now. memory usage does only increase slowly. Here you can find a few videos showing the activity window of MacOS 11.6.4. when Jamulus is in front or not and when quitting Jamulus.
http://www.vaskez.de/jamulus_bug/Jamulus_in_front.mov http://www.vaskez.de/jamulus_bug/Jamulus_not_in_front.mov http://www.vaskez.de/jamulus_bug/Quit_Jamulus.mov
So it looks like the switch to QT6 at least brings some changes. I hope this is helpful.
Hi, under Jamulus 3.9 beta 2 and MacOS 11.6.8 this bug is no longer exiting. I had a session today with Jamulus running in the background a lot and it remained responsive and there was no hang at all :-)
Great improvement!
Thanks!
@MattMerz-Violin
Cheers
@RonCohen1 @Rob-NY @chrisrimple,
Can you comment at all on the 3.9.0beta2 release?
Thanks
As there is at least one positive report that this issue should be fixed as of 3.9.0, I'm closing this for now. If someone has different experiences, please comment or open a new issue. Thanks.