waveform scrolling

[robi970]

Bug Description

I installed Mixxx 2.4 beta and started it.
I quickly realized that the waveforms, spinnys and elapsed time display are displayed as if "4-5 frames per second" is set.

on the same PC I keep Mixxx 2.2.4 installed, which obviously still works perfectly

Version

2.4 beta

OS

Win10 pro 64bit - AMD ryzen 5 3600; 16GB ram; AMD radeon R9 200 series

[JoergAtGithub]

• Could you please share a screenshot of the Waveforms tab in the Mixxx preferences!
• How much CPU and GPU load does the Windows Task Manger show?
• Did you also tried Mixxx 2.3 builds, or only 2.2 and 2.4 beta?

[robi970]

sorry, but i can't figure out how to insert an image in this editor...

Anyway:
wavwforms section settings

• RGB (GL)
• RGB
• 60 fps (but it's also equal to 50fps)...
• zoom level 25%

while playing, the preferences say: "average frame rate 6.67"
music stopped: "average frame rate 12"

CPU usage - 4%
RAM - 22%
GPUs - 2% max

I uninstalled Mixxx 2.3.5 to install Mixxx 2.4. It worked fine.
I always keep the 2.2.4 build installed because with it I manage timecode vinyls better than the 2.3 versions

PS: I've now discovered how to attach a photo :P

[JoergAtGithub]

Could you please try all waveform types available in the top selector. Does any waveform type shows different frame rates?

[robi970]

with all waveforms the value is always around 6.67, except with HSV (FPS: 7.50)

same thing also changing the values ​​of the second selector

(OT question: in this editor is it possible to write in your own language, or do I have to continue with google translate?)

[JoergAtGithub]

Please write in English!

[JoergAtGithub]

@m0dB Could you have a look

[JoergAtGithub]

Does it help if you start with .\mixxx.exe --disableVuMeterGL

[robi970]

switched to 15 fps (both during play and stop)

[m0dB]

I have no idea, this is very strange and the first time something like this has been reported.

To be sure: 2.3.5 runs as 60 fps?

I will create a build with some logging, but it might take a while, sorry.

[m0dB]

Are you having no fps issues with other applications (games)?

Question for @daschuer : are we configuring Qt on windows with
configure -opengl dynamic ?

[JoergAtGithub]

It's dynamic and ANGLE is used when the OPENGL driver is missing or blacklisted by Qt. If ANGLE is used, you see it clearly in the driver information in the waveform preferences.

[m0dB]

Thanks, @JoergAtGithub ! So I understand that in this case ANGLE isn't used because a proper OpenGL driver is detected. It might be interesting to see if forcing ANGLE makes a difference, right? Have you ever tried that yourself?

@robi970 can you try running with environment variable QT_OPENGL=angle? Go to the folder where you have your mixxx.exe in the File Explorer, open a command prompt by typing cmd in the address bar, and in the command prompt type:

set QT_OPENGL=angle
mixxx.exe

(Note that I am clutching at straws here, not being a windows user myself)

[robi970]

sorry for the delay...

• Mixxx 2.3.5 ran perfectly at 60fps (and Mixxx 2.2.4 still runs perfectly at 60fps)
• tomorrow I will try to open Mixxx as you suggested

[Swiftb0y]

Also grasping at straws here, but you mentioned this:

I installed Mixxx 2.4 beta and started it.
I quickly realized that the waveforms, spinnys and elapsed time display are displayed as if "4-5 frames per second" is set.

I'm pretty sure the elapsed time display is not hardware accelerated so that leads me to believe missing hardware acceleration might not be the problem. Whats your audio buffer size set to?

If I force some weird audio circumstances (mind this is on linux with pipewire, so not quite the same), I can force some low-fps behavior that is not because the waveform rendering is too slow (see the low amount of dropped frames compared to the actual fps) but I think because the update of the playposition depends on the buffer size. Here's a screen recording showing the issue in action:
screencast.webm

[robi970]

Here you are:

• the end of the prompt list, after following your instructions
  

• the warning (unfortunately in Italian) that appears when starting Mixxx:

"direct rendering" is not enabled on your machine

this means that displaying waveforms will be very slow and can take a toll on your CPU.
Update your configuration to enable Direct Rendering, or disable waveform display in Mixxx Preferences by selecting "blank" as waveform display in the "interface" section

how do i update the configuration?

[m0dB]

Oh, this direct rendering warning is very relevant. Now, how to fix this, I have no idea.

[robi970]

since in this editor it is possible to insert videos:

2023-06-11.18-54-31.mp4

[m0dB]

Any windows / AMD radeon users who can comment on this? Any idea how to enable Direct Rendering?

[atskler]

I can reproduce the problem on a really old HP Compaq 8510P notebook, with Windows 8.1 and with ATI Mobility Radeon HD 2600.

[m0dB]

@robi970 can you please try again with a recent 2.4 beta? There was a problem with OpenGL version detection which was was fixed #11673 . This fix solved the warning about Direct Rendering for specific Linux drivers, so maybe it also solves it for you on Windows.

[atskler]

@m0dB for me the problem is still there with:
2.4-beta-28-g7dcadb17ab (HEAD)
https://github.com/mixxxdj/mixxx/actions/runs/5348576035

[JoergAtGithub]

Could you try to set the Windows environment variable QT_NO_OPENGL_BUGLIST (value doesnt matter) before starting Mixxx.
For details see: https://doc.qt.io/qt-5/windows-requirements.html#dynamically-loading-graphics-drivers

[atskler]

@JoergAtGithub the problem is the same with:
set QT_NO_OPENGL_BUGLIST=1
mixxx.exe

[JoergAtGithub]

Do you have libEGL.dll and libGLESv2.dll in your Mixxx program directory? Could you try to replace these two file with the version from Mixxx 2.3.5?
There might be also d3dcompiler_47.dll, but I guess this is not needed by Mixxx.

[atskler]

That two dll is there.
The problem is still there with that two dll copied from 2.3.5.

[JoergAtGithub]

Thanks for testing! Seems to be a dead end. Maybe you can play with the other environment variables described in: https://doc.qt.io/qt-5/windows-requirements.html#dynamically-loading-graphics-drivers

[atskler]

Mixxx also can be started without that two dll and with the 2.4 beta the problem is still there, and 2.3.5 works correctly.

[JoergAtGithub]

These two DLLs are the libraries for the ANGLE emulation of OPENGL. It is used by Qt in case, that the official graphic adapter driver is blacklisted or does not support OPENGL at all. ANGLE is a fast emulation using DirectX.
If Qt could neither find a native OpenGL driver, nor ANGLE, it falls back to Sowtware emulation using the CPU instead of the GPU. It's obvious that your system falls back to this slow software emulation - but I don't know why.

[atskler]

Is it possible, that we just raised the minimum required OpenGL version higher than 3.3?

robi970 has the problem with:
OpenGL 4.6.13559 Compatibility Profile Context 26.20.12028.2 (AMD Radeon R9 200 Series)

[robi970]

@robi970 can you please try again with a recent 2.4 beta? There was a problem with OpenGL version detection which was was fixed #11673 . This fix solved the warning about Direct Rendering for specific Linux drivers, so maybe it also solves it for you on Windows.

I reinstalled Mixxx 2.4 beta, just downloaded from the site... (I hope that is the correct version).
alas no, nothing has changed:

[atskler]

@JoergAtGithub is there a 2.4 beta build for Windows with QOPENGL=OFF?

[JoergAtGithub]

@atskler Can you confirm, that you also get warning dialog at startup shown here: #11617 (comment)

[JoergAtGithub]

Since you both use AMD GPUs, here are my driver settings. I have 60fps with these settings:

[JoergAtGithub]

I noticed in your screenshots of the waveform preferences, that there is always an exact integer factor between target framerate and the real framerate:
60/6.67= 9
60/12.00=5

Could you try to adjust the target frame rate to other values. Does the integer factor remain?

[Swiftb0y]

@robi970 can you check out the newest beta version and look for the line starting with "debug [Main] Supported OpenGL version: " in the debug log? What version does it print exactly?

I'm a little confused because the "Direct Rendering" Warning should only occur if the version is not sufficient. Since the version string does say 4.6 but its not detected correctly, there might be something wrong with the detection logic.

mixxx/src/mixxxmainwindow.cpp

Lines 1189 to 1194 in a5ae80a

	if (!factory->isOpenGlAvailable() && !factory->isOpenGlesAvailable() &&
	pConfig->getValueString(ConfigKey("[Direct Rendering]", "Warned")) != QString("yes")) {
	QMessageBox::warning(nullptr,
	tr("OpenGL Direct Rendering"),
	tr("Direct rendering is not enabled on your machine.<br><br>"
	"This means that the waveform displays will be very<br>"

[atskler]

@atskler Can you confirm, that you also get warning dialog at startup shown here: #11617 (comment)

Yes, if I start it with:
set QT_OPENGL=angle
mixxx.exe

And Mixxx will not even start, just crashes.
mixxx.exe has stopped working
and once more:
mixxx.exe has stopped working

[atskler]

My AMD Catalyst settings:

[JoergAtGithub]

Can you vary: Wait for vertical refresh

[atskler]

I noticed in your screenshots of the waveform preferences, that there is always an exact integer factor between target framerate and the real framerate: 60/6.67= 9 60/12.00=5

Could you try to adjust the target frame rate to other values. Does the integer factor remain?

It will differ a bit if the frame rate is odd number. For example 37 will give fluctuating frame rate: 11.43, 11.62.

[atskler]

"Direct Rendering" Warning

@Swiftb0y That warning happens with:
set QT_OPENGL=angle

[atskler]

Can you vary: Wait for vertical refresh

@JoergAtGithub

From left to right there are the following options for:

Wait for vertical refresh:

Performance

1. Always off
2. Off, unless application specifies
3. On, unless application specifies
4. Always on

Quality

With option 1) the fps problem goes away.

[atskler]

The warning and the crash with: set QT_OPENGL=angle remains.

[JoergAtGithub]

With option 1) the fps problem goes away.

Important finding!

Than the ANGLE issue is an independend issue.

[robi970]

@Swiftb0y the Mixxx version reinstalled yesterday is as follows:

[JoergAtGithub]

@robi970 Do you have the "Wait for vertical refresh" setting in your AMD driver too? Could you try if it solves the issue for you too?

[m0dB]

In the legacy implementation we had this:

 243 #if defined(__APPLE__)
 244         // On OS X, syncing to vsync has good performance FPS-wise and
 245         // eliminates tearing.
 246         glFormat.setSwapInterval(1);
 247 #else
 248         // Otherwise, turn VSync off because it could cause horrible FPS on
 249         // Linux.
 250         // TODO(XXX): Make this configurable.
 251         // TODO(XXX): What should we do on Windows?
 252         glFormat.setSwapInterval(0);
 253 #endif

I thought I carried this over to the QOpenGL implementation but I see that isn't the case. This might also solve the issue.

[JoergAtGithub]

@atskler @robi970 I created a PR with the potential fix mentioned by m0dB above: #11681
Please test, if this works with more options of "Wait for vertical refresh".

[atskler]

@atskler @robi970 I created a PR with the potential fix mentioned by m0dB above: #11681 Please test, if this works with more options of "Wait for vertical refresh".

@JoergAtGithub With the fix only option 4. brings forth the fps problem. With options 1-3 the fps is normal.

@robi970 you will find the installer on the following link for this fixed build, under the "Artifacts" section: https://github.com/mixxxdj/mixxx/actions/runs/5371666174

[JoergAtGithub]

@JoergAtGithub With the fix only option 4. brings forth the fps problem. With options 1-3 the fps is normal.

Great, this is the expected behavior, because "4. Always on" should overwrite the setting inside the application (Mixxx) by definition. Waiting for confirmation by @robi970

[atskler]

Great, this is the expected behavior, because "4. Always on" should overwrite the setting inside the application (Mixxx) by definition. Waiting for confirmation by @robi970

Probably @robi970 should check his gpu settings also if this fix will not work for him, because for example on your system @JoergAtGithub the "Wait for vertical refresh" is set to "Always on". But is that by default?

Did you managed to reproduce the problem with that setting?

[JoergAtGithub]

Today I tried different settings an it always runs with 60fps - I don't remember what the default was, when I initally set it up.
I've to add, that my systems AMD Ryzen 7 PRO 6850U contains one of the most powerful mobile GPUs you can get.

[robi970]

I fear that I will be forced to wait for new Mixxx releases that better adapt to my system:
I'm too hard, alas, to follow these topics and these instructions with only the use of google translate...

for example: my PC has no Catalyst Pro Control Service

[JoergAtGithub]

Just test the latest 2.4 Beta

[robi970]

Just test the latest 2.4 Beta

sorry for the delay.
with the newly downloaded and installed version, there are no longer the problems encountered previously