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

git-developer commented 8 months ago

Bug Description

What happened?

On upgrade of Mixxx to v2.4.0, the waveform type is changed to GLSL using 60 fps.

What's wrong with that?

This change introduced a massive performance drop and I didn't understand the cause. Before the update, the system was able to handle a latency of 5ms without problem. After the update, CPU usage is about 100% and audio is choppy unless I increase latency to 40ms. I installed a low latency kernel, with no effect. I downgraded to 2.3.6, with no effect - because the new default setting was written to my user config and survived the downgrade.

I carefully read the News but had no clue. Finally I read the Changelog and found out that the waveform settings might be related. With a setting of plain RGB@30fps the problems are gone and the system behaves as before.

What do I expect instead?

Keep user settings untouched on updates. I'd prefer to leave it up to the user if a proposed change is applied or not. Ask the user on first start after an update if s/he'd like to try the new proposed setting instead of applying it without notice.

Environment

For the record, here are some specs of the affected system (which might be old but performs perfectly running Mixxx):

AMD Athlon X2 3800+
6 GB RAM
Dedicated graphics card: NVIDIA Corporation GT218 [GeForce 210] with nouveau driver (no proprietary driver available)
OpenGL 3.3 Compatibility Profile Mesa 23.2.1-1ubuntu3.1~22.04.2 (NVA8)

Version

2.4.0

OS

Ubuntu 22.04

git-developer commented 8 months ago

daschuer commented 8 months ago

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?

git-developer commented 8 months ago

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

Type	fps	CPU	Notes	Frame Drops
Empty	30	25%	2 Tracks loaded, idle	0
Empty	30	35%	1 Track playing	0
Empty	30	40%	2 Tracks playing	0
Simple (GLSL)	30	30%	2 Tracks loaded, idle	0
Filtered (GLSL)	30	30%	2 Tracks loaded, idle	0
RGB	30	35%	Idle
RGB	30	70%	2 Tracks loaded, idle	~2fps
RGB	30	85%	1 Track playing	few
RGB	30	90%	2 Tracks playing	few
RGB	>40	>100%	2 Tracks loaded, idle	~10fps
RGB (GLSL)	30	39%	2 Tracks loaded, idle	0
RGB (GLSL)	30	40%	1 Track playing	0
RGB (GLSL)	30	45%	2 Tracks playing	0
RGB (GLSL)	40	43%	2 Tracks loaded, idle	~1fps
RGB (GLSL)	50	47%	2 Tracks loaded, idle	~1.5fps
RGB (GLSL)	60	50%	2 Tracks loaded, idle	~2.5fps
RGB (Legacy, GL)	30	50%	2 Tracks loaded, idle	few
RGB (Legacy, GLSL)	30	50%	2 Tracks loaded, idle	few
HSV	30	80%	2 Tracks loaded, idle	~2fps
HSV (GLSL)	30	35%	2 Tracks loaded, idle	0
VSyncTest (GL)	30	30%	2 Tracks loaded, idle	0
VSyncTest (GL)	40	35%	2 Tracks loaded, idle	few
VSyncTest (GL)	50	38%	2 Tracks loaded, idle	~2 fps
VSyncTest (GL)	60	42%	2 Tracks loaded, idle	~2 fps

2.3.6

Type	fps	CPU	Notes	drops
RGB	30	25%	Idle	? (didn't write down)
RGB	30	45%	2 Tracks loaded, idle	?
RGB	30	60%	1 Track playing	?
RGB	30	65%	2 Tracks playing	?
RGB (GLSL)	30	55%	2 Tracks loaded, idle	~15fps
RGB (GLSL)	30	55%	1 Track playing	~10fps
RGB (GL)	30	55%	2 Tracks loaded, idle	?
RGB - Qt (GL)	30	>100%	2 Tracks loaded, idle	?

git-developer commented 8 months ago

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?

JoergAtGithub commented 8 months ago

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

daschuer commented 8 months ago

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.

git-developer commented 8 months ago

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:

an old 2.3-beta that was lying around (2.3-beta-4293-g2945f43418)
2.3.3 (from impish)
2.3.6 (from bionic)
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!

daschuer commented 8 months ago

Thank you for the kind words!

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

m0dB commented 1 month ago

We could automatically change the frame rate from 60 to 30 if we detect an excessive amount of frame drops (and even lower if this continues at 30 fps) and show a popup along the lines of "The waveform display frame rate has been lowered to X fps due to an excessive number of frame drops. Try changing to a different waveform display type in the preferences".

mixxxdj / mixxx