vinyl signal fifo warnings when spinny widgets are not visible

[Owen Williams]

If I change desktops such that mixxx isn't visible, I get spew in the log:

Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 1
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 2
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 3
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 0
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 1
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 2
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 3
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 0
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 1
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 2
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 3
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 0
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 1
Warning [VinylControlProcessor 1]: VinylControlProcessor could not write signal quality report for VC index: 2

If I switch back to the desktop with mixxx, the framerate can start to stutter and the whole gui slows down. Hiding and unhiding the spinnies fixes the issue.

 I'm guessing this has something to do with the gl context when the application window is hidden, but that shouldn't affect the basic fifo operation

[RJ Skerry-Ryan (rryan)]

Could you printline calls to addSignalQualityListener / removeSignalQualityListener and startTimer/killTimer/timerEvent calls in VinylControlManager?

WSpinny registers itself on showEvent and unregisters itself on hideEvent. If there are no signal listeners registered with VinylControlManager then it stops reading from the signal quality FIFO and updating listeners.

Since that log message is spewing the VinylControlProcessor clearly believes signal quality reporting is still enabled. If everything was working properly VinylControlProcessor would still be reading from the FIFO on a timer but since the FIFO is overflowing that suggests either its timer is not active (which should in turn mean no signal quality listeners are active) or its timer is not firing frequently enough to process incoming quality reports (unlikely).

add/remove/show/hide/timer events all (should be) in the main thread so it's probably not a concurrency issue

Possible causes:
- Our volatile bool VinylControlProcessor::m_bReportSignalQuality isn't working as intended and the processors are not getting the message to stop writing signal quality reports.
- Some logic error with how WSpinny and VinylSignalWidget register/unregister themselves.
- Something else? The manager's timer event shouldn't be affected by being off screen or not... it would be very strange (and other stuff would be broken) if Qt/X11 stopped servicing timers for off-screen windows.

[Owen Williams (ywwg)]

After testing, this only occurs when one audio input is used to control two different decks, eg single-deck mode or 4-deck mode using 2 turntables.

[Owen Williams (ywwg)]

I also think maybe this is just a contention halt. I'm not hiding the spinnies, just moving desktops so they aren't onscreen. That should trigger a show-hide event. Is it more likely that the GUI thread is getting locked up while compiz tries to figure out what's going on and the fifo correctly fails?

[RJ Skerry-Ryan (rryan)]

Could you stick some printlines in the timer handler and see if you see something like delays in timer processing?

HideEvents might be delivered when a window goes off screen. The Qt documentation is unclear but I could see it happening:

"Note: A widget receives spontaneous show and hide events when its mapping status is changed by the window system, e.g. a spontaneous hide event when the user minimizes the window, and a spontaneous show event when the window is restored again. After receiving a spontaneous hide event, a widget is still considered visible in the sense of isVisible()."

The FIFO is 256 items long -- with single-deck vinyl control that means we write one quality report per callback. For the FIFO to overflow you would need to write 256 items between timer ticks (we ask to get a timer event every 66ms but it's always a lower bound.)

What's your latency?

You could try bumping the FIFO size 10x or something to see. If it was a logic error it would fill up regardless -- if it's not reading the FIFO fast enough then increasing the size would help.

[Owen Williams (ywwg)]

yeah I stuck in some printlines but they didn't reveal anything interesting. I'll try again.

[Owen Williams (ywwg)]

still seeing this occasionally. I'm thinking bumping up the fifo size would be a good idea (since it's one update per buffer)

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7858