Waveform jerking with Windows 11 and GeForce GTX770

[daschuer]

Bug Description

RGB (GLSL) runs only with 44 f/s (of 60)
RGB (GL) -> 50 f/s
RGB -> 55 f/s

RGB wuns with 30 f/s if 30 is selected, but the jerking does not stop and the droped frames are keeping counting.

My guess is that there is a new anti tearing code active.

Using 2.4-alpa or @m0dB #10989 does not make a difference.
Where the later gives extra smoothness on my Ubuntu Focal with intel GPU.

Version

2.3.4

OS

Windows 11

[daschuer]

After setting the v-sync settings in the NVIDIA control panel to various values and back to NVIDIA Default "For 3D applications"
the major jerking was gone. All waveforms are now running without dropped frames and at 60 f/s.

However there is every 5 seconds a phase of 1 s with a micro jitter. All v-sync settings are effected.
I have also updated the driver form 456 to 474 but without any effect.

This issue is the same for all tested Mixxx versions including #10989

[JoergAtGithub]

Could you please test if this is fixed after merging #11681

[m0dB]

Can you check if this still is the case?

[m0dB]

And can you check if this branch makes a difference: https://github.com/m0dB/mixxx/tree/vsyncthreadless

(This is an experimental branch that does the vsync timing directly in the main thread instead of using a separate thread signaling the main thread, thus avoiding the overhead and impression of the signaling and the hassle of the semaphore)

[JoergAtGithub]

This branch doesn't start up:

DEBUG ASSERT: "addShaderFromSourceCode( GLShader::Vertex, vertexShaderCode)" in function void __cdecl mixxx::Shader::load(const class QString &,const class QString &)

Qt5Core.dll!00007ffe92d305c8()
Qt5Core.dll!00007ffe92d2e83d()
mixxx.exe!mixxx::`anonymous namespace'::handleMessage(QtMsgType type=QtCriticalMsg, const QMessageLogContext & context={...}, const QString & input={...}) Line 355
	at C:\Users\Joerg.WORLDWARTWEB\source\repos\JoergAtGithub\mixxx\src\util\logging.cpp(355)
[External Code]
mixxx.exe!mixxx::Shader::load(const QString & vertexShaderCode, const QString & fragmentShaderCode={...}) Line 31
	at C:\Users\Joerg.WORLDWARTWEB\source\repos\JoergAtGithub\mixxx\src\shaders\shader.cpp(31)
mixxx.exe!mixxx::EndOfTrackShader::init() Line 28
	at C:\Users\Joerg.WORLDWARTWEB\source\repos\JoergAtGithub\mixxx\src\shaders\endoftrackshader.cpp(28)
mixxx.exe!allshader::WaveformWidget::initializeGL() Line 47
	at C:\Users\Joerg.WORLDWARTWEB\source\repos\JoergAtGithub\mixxx\src\waveform\widgets\allshader\waveformwidget.cpp(47)
[External Code]
mixxx.exe!OpenGLWindow::event(QEvent * pEv=0x00000017d89cbfd0) Line 67
	at C:\Users\Joerg.WORLDWARTWEB\source\repos\JoergAtGithub\mixxx\src\widget\openglwindow.cpp(67)
[External Code]
mixxx.exe!`anonymous namespace'::runMixxx(MixxxApplication * pApp=0x00000017d89cfbd8, const CmdlineArgs & args) Line 82
	at C:\Users\Joerg.WORLDWARTWEB\source\repos\JoergAtGithub\mixxx\src\main.cpp(82)
mixxx.exe!main(int argc=1, char * * argv=0x00000195c60ac8d0) Line 213
	at C:\Users\Joerg.WORLDWARTWEB\source\repos\JoergAtGithub\mixxx\src\main.cpp(213)
[External Code]

[m0dB]

can you try again?

[JoergAtGithub]

Now it runs!
Note, that I don't have the the slow framerate on one of my systems, reported here (independend of the branch). But I always see frame drops, when movig other windows etc.
With this branch, these frame drops increased if they occur, but if Mixxx just plays a track and I don't touch anything there are no frame drops.

My assumptions:
I guess my frame drop issue has it's origin in a blocked Qt event queue. According to my measurements, the dedicated vysnc thread generates a very accurate timing signal. But receiving the signal is only possible, if the receiver can not read the slot because Qts global event queue is locked by another thread in this moment.

In general worker threads, where no Qt event queue is started to receive events, run with reliable speed. Sleep functions only depend on the scheduler, and these work much better than a timer.

BTW: I found this post interesting to read: https://forum.qt.io/post/727544

[daschuer]

I got access to the original test device. I still see a micro jitter in intervals. The vsyncthreadless branch is unfortunatly crashing:

debug [0x15d54a22970] SSE: Enabling denormals to zero mode
debug [Main]    Actual sample rate:  48000 Hz, latency: 42.6667 ms
debug [0x15d54a22970] SSE: Enabling flush to zero mode
debug [Main] SoundDeviceNetwork - open: "Network stream"
debug [0x15d54a22970] Denormals to zero mode is working
debug [Main] SoundDeviceNetwork - Maximum: 1024 frames/buffer @ 48000 Hz = "21 ms"
warning [Engine] underflowHappened code: 25
debug [Main] Using "Lautsprecher (High Definition Audio Device)" as output sound device clock reference
debug [Main] 2 output sound devices opened
debug [Main] 0 input sound devices opened
warning [Engine] SoundDevicePortAudio: Audio API provides invalid time stamps, syncing waveforms with a CPU Timer DacTime: 1227.85 EntrytoDac: 0.014 TimeSinceLastCb: 0.0219416 diff: -0.0257909
warning [Engine] underflowHappened code: 25
warning [Main] QOpenGLShaderProgram::uniformLocation(matrix): shader program is not linked
warning [Main] QOpenGLShaderProgram::uniformLocation(sampler): shader program is not linked
warning [Main] QOpenGLShaderProgram::attributeLocation(position): shader program is not linked
warning [Main] QOpenGLShaderProgram::attributeLocation(texcoor): shader program is not linked
warning [Main] QOpenGLShaderProgram::uniformLocation(matrix): shader program is not linked
warning [Main] QOpenGLShaderProgram::uniformLocation(sampler): shader program is not linked
warning [Main] QOpenGLShaderProgram::uniformLocation(color): shader program is not linked
warning [Main] QOpenGLShaderProgram::attributeLocation(position): shader program is not linked
warning [Main] QOpenGLShaderProgram::attributeLocation(texcoor): shader program is not linked
warning [Engine] underflowHappened code: 24
warning [Engine] underflowHappened code: 25 

This reveals the issue that the jitter may come form the Invalid timestamp form the Soundcard.

[m0dB]

@daschuer I added a check to make sure initializeGL has been called, I hope that fixes the crash.

@JoergAtGithub

I guess my frame drop issue has it's origin in a blocked Qt event queue. According to my measurements, the dedicated vysnc thread generates a very accurate timing signal. But receiving the signal is only possible, if the receiver can not read the slot because Qts global event queue is locked by another thread in this moment.

Yes, blocked by another thread, or because of an event being handled in the main thread itself. And that is what this approach tries to avoid.

There is IMO no added value of using a separate thread for the vsync signal. There would be, if the drawing could be triggered directly from the vsync thread, but since it's still the main thread that has to handle the event, we could as well do the triggering in the main thread itself, and arguably better:

I added an idle callback, which is called when there are no events left on the queue. In the idle callback, if I see that the swap is due within a certain time window, I sleep the time that is remaining time and I do the swap. This reduces the risk that more events get added that would delay the swap.

Additionally, I also checked if the swap is due in the eventFilter, basically giving priority to the swap over the event handling. But I removed that because of the crash you experienced. Now, it might be that with my last change this can be put back (you could try this by uncommenting the commented lines at the top of MixxxMainWindow::eventFilter)

Of course the ideal solution would be to do the rendering and swapping from the vsyncthread itself. This requires moving the QOpenGLContext to the VSyncThread. I got this working until a certain point and it indeed solves all the problems (like framedrops when scrolling the library). The problem is that Qt sometimes still uses the QOpenGLContext from the main thread (e.g. when resizing or when changing the layout) which causes a crash, and I have found no way around that...

[JoergAtGithub]

I think the real bug fix would be, to find out what blocks the Qt Event Queue and eliminate this. But this might be a very difficult task.

The timers also depend on the Qt Event Queue. You can't trust the time period of them. If the Qt Event Queue were locked, than it sends several events at once after the lock. This does not happen with the free running vsync thread, which has no Qt Event Loop listener started.

[m0dB]

What timers do you mean? I am not using any QTimer except for the idle timer which isn't a real timer.

[JoergAtGithub]

Ah good, than my sentence about the timer doesn't apply here.

[m0dB]

To be clear, this branch is just an experiment I did and I was curious to see if it would make a difference for this issue.

[JoergAtGithub]

I think the original issue is solved. Even on my old Windows7 dual core laptop with poor GPU, I get 60fps with 2.4 and the default ST_TIMER.
What remains are random lag/framedrops, and also full repaint of the main window stops the waveform for some time.

[ywwg]

ok to close this bug then? we know there are random lag issues sometimes but I don't think they block 2.4.

[daschuer]

We have still work in progress regarding waveform jerking. Like this one #12516
However there is no reason to fix it before the release. I am just curious to check if the original issue of the this bug has been changed. So lets keep it open and just remove it form the milestone.

[JoergAtGithub]

But the original report was about low frame rates on one specific grapic adapter. We should close it, when this is confirmed to be fixed.

[daschuer]

I just did the test with Windows 11 2023-10 Update KB4023057
Unfortunately the periodical micro jitter described in #11399 (comment) is still there, with the ST_TIMER vsync mode.

ST_FREE runs OK, ST_PLL is broken by heavy jitter and frame-rates dropping to 50 Hz.