Update to v2.4.0 drives older system unusable (caused by new waveform default GLSL@60fps) about mixxx HOT 8 OPEN

Might be related: #12841

from mixxx.

We made the choice to force GLSL 60 fps, because it will be on the GPU which is bored anyway. Even the oldest devices should ba capable to do it flawlessly.

You bug-report however is a prove that it is not that simple. We should probably revert the change. in 2.4.1.

CPU usage is about 100%

My fist guess is that the CPU has taken over the rendering. However the OpenGL String indicates that your Graphic Card IS used.
Maybe something else is locking the CPU.

You are now at 2.3.6 right? Do the GLSL types work there?
You may start Mixxx with the --developer command line option and you will find the V-Sync test waveforms.
Are you able to use that at 60 Hz? You should see a pink flicker area. White or red moments indicates a frame drop.

Does using Spinnies make a difference?

from mixxx.

Thanks for your quick response!

I made a few tests, here are the results.

Common notes:

• Monitor is 1680x1050@60Hz.
• Spinnies make no (<3%) difference.
• Frame drops are taken from the info area at the bottom of Settings / Waveforms.
• CPU usage is taken from the mixxx process in top.
• I didn't consider audio quality at all in this tests, just wrote down numbers.

My interpretation of the results:

• GLSL performs better than no-GLSL.
• Frame drops occur even when cpu usage is OK.
• FPS setting has a big impact on cpu usage and frame drop count.
• There's no big difference between "loaded" and "playing", but there's a big difference between "no waveform rendering" and "static (i.e. not moving) waveform rendering".

I'm ready to provide further results, just tell me what you're interested in.

2.4.0

2.3.6

from mixxx.

Looking at the numbers, I don't really understand anymore why I had such problems after the update. I can't reproduce the behavior anymore. It's currently no problem to use RGB - GLSL@60fps; I see a few frame frame drops but no effect on mixing. I can even lower the latency down to 1.5ms without chopping. Sorry for the fuss.

Maybe the low latency kernel has a bigger impact than I first thought. Right after the update to 2.4, the generic kernel was used. I can't remember exactly the waveform settings before I started fiddling. So maybe the combination of generic kernel + RGB (no GLSL) + 60 fps was the cause for the massive performance degradation.

I remember a single other thing that could be related: I'm using Vinyl Control, and the signal quality was quite bad after the update (hardware connection was a little shaky). Does a bad VC signal have significant impact on CPU usage?

from mixxx.

Do you display the Vinyl Control signal in the spinnies? These are displayed using OpenGL too. Maybe there's an influence?

from mixxx.

On one hand I am glad you issue is solved. On the other hand it is now harder to remove the trap for other users.

Do we a theory what might has happened?

Did you ONLY upgrade from Mixxx 2.3.6 to 2.4.0 and back or where other packages updated between your last use of the original good 2.3.6 installation?

A high CPU with GLSL is an indicator that the MESA gallium CPU rendered is used. This is significant slower compared to the native non GL types. In this case the OpenGl string in the waveform preferences reflects that. Maybe it was a glitch with you Graphic cart after suspend or such?

The default Linux scheduler does not allow user threads with higher priorities. That's why the audio thread is treated as a normal thread and might be blocked by the renderer thread. This can be fixed even with the original kernel by setting limits.conf and adjust user group.
The installation of Jack does it automatically for you.

I wonder how your old setup was good without the rt audio thread.

The rt-kernel adds alternative scheduler features and does for my experience not perform significant better than a recent default kernel in the Mixxx case. (It does no harm also)

Hyperthreading is another topic that may applies ...

Another interesting takeaway of your measures it that the 2.4.0 RGB waveform performans is worse compared to 2.3.6. It is interning if we can revert to the old performance.

from mixxx.

Do you display the Vinyl Control signal in the spinnies?

Yes, indeed, good idea! But whatever I tried, behavior was the same with spinnies enabled or disabled.

Did you ONLY upgrade from Mixxx 2.3.6 to 2.4.0 and back or where other packages updated between your last use of the original good 2.3.6 installation?

The previous version was 2.3.3. To be honest, I can't tell if other packages have also been updated, sorry.

Maybe it was a glitch with you Graphic cart after suspend or such?

Hard to say... but the machine does not suspend nor hibernate.

Thanks for your hints on kernel, hyperthreading and the like. I carefully read the wiki article about Adjusting Audio Latency when I setup the system and configured everything as proposed, except the kernel. Jack is not involved.

I just tried to reproduce the issue: I booted the generic kernel and tried one after the other:

1. an old 2.3-beta that was lying around (2.3-beta-4293-g2945f43418)
2. 2.3.3 (from impish)
3. 2.3.6 (from bionic)
4. 2.4.0

They all behave the same: with a latency of 5.8ms, there are no problems with audio quality at all, no matter what I try, Vinyl Control, effects, waveform changes. With one exception: all legacy GLSL waveforms introduce heavy chopping, and I have to lift the latency to 40ms to fix that. "All legacy GLSL waveforms" means: the label in the settings contains "GLSL" for 2.3.x and "GLSL (legacy)" for 2.4.0.

So, what happened after all?
I have the assumption that after the update to 2.4.0 my config had the waveform set to GLSL (legacy). I just don't know why. I don't think that the update set this value (not sure, though) - do you think this could be possible? Maybe when coming from an older version? I also don't think that I configured this by myself.

From my perspective, this issue may be closed, I leave this up to you.

One last thing: it's important for me to say Thank You for taking my issue seriously and giving helpful advice. Your quick and in-depth support is great and makes this project a good example for others!

from mixxx.

Thank you for the kind words!

I will double check it on my system and than we can decide how to continue.

from mixxx.