touching jog wheel causes too much adjustment, waveform out of sync with audio

[ywwg]

Bug Description

A couple times during practice, when I touch the jog wheel to adjust the sync (my controller uses the "jog" parameter), a weird thing happens:

1. the track speed changes MUCH more than it should. the audio bends noticeably.
2. But, the waveform display does not seem to move a lot! In fact, the audio becomes out of sync with the waveform display. The beats are noticeably misaligned from the waveform and beat display.

If I pause and play, the waveform/audio sync is restored. Nothing else about the waveform display looks incorrect, it's just in the wrong place.

Version

HEAD

OS

Ubuntu 22.04

[ywwg]

I will try disabling the new opengl stuff and see if that does anything -- I don't expect it to

[ywwg]

I suspect this is a bug with the Traktor S3 script. Merging the rewrite will likely fix it

[tekhedd]

I was worried it was just me, or something with my VCI-400 script. Since the wheel support is very generic, I don't see how that could happen. I thought it was my hardware so I bought a new laptop, did not fix it. Since it happens randomly and only when two decks are going, I honestly thought I was just screwing up for a LONG time...this might be affecting several scripts and quietly making DJs less confident in Mixxx. Last time I saw it was last night, with two decks playing, using pitch offsets but keylock off.

Occurs even if "vinyl" is turned off, it's not just me brushing the touch sensor.

I have been noticing the same thing, since about mixxx 2.3.8 or 2.3.6 (not sure, one of the later updates to 2.3). It also definitely happens with 2.4.1 on the latest ubuntu releases (lubuntu LTS).

It doesn't seem to be related to the output audio or audio buffer. Usually happens when I have two (or more) decks going, and when I go to gently adjust the timing of one of the decks instead of getting a tiny pitch bend I get a 2+beat random skip. Sometimes the track display is still correct, sometimes it becomes offset from the audio and so I have to correct and beat match by ear from then on.

It is difficult to reproduce and intermittent. I suspect it has to do with midi overload. I will update my jog script to log any "large offsets" and see if I can track it down.

Edit, also seems to happen mostly with very small movements with otherwise idle two-deck-play. Could it be the controller is sending an jog offset of "0"? It's also a high resolution wheel, so maybe the offset of 1 tick (engine.setValue(..., 'jog', +-0.10667)) rounds off to something weird in the mixxx jog engine but only under certain conditions?

Edit, nah, not the jog code. Correlates with "Recoverable MP3 header decoding error"? Possible jog-during-recovery issue?

[ywwg]

I have not experienced this issue in a long time fwiw

[tekhedd]

I can see why most people don't have the issue. It appears to be I/O related, and the kind of thing that you just go "well I'll try another port/computer". I have had intermittent (and frustrating) experiences with this issue for the last several months, but now I have a setup where it is repeatable, so I am hoping to at least know the source of the issue before moving on. :)

It seems like I am getting duplicated USB MIDI packets for the jog wheel (or whatever), and this seems to happen most often after seeking, which is to say during buffer-feeder I/O. My first clue was that the entire UI would freeze for a few seconds when I moved a jog wheel and also I could see from the output that it buffer feeder was working, usually after seeking. This behavior became different when I switched timing to the network adapter, and instead I got weird slowdowns, so clearly the audio clock freezes during this. (Hmm, typing this makes me want to try a different cable and or port).

Regardless of the source, the failure mode is what I'm actually interested in, here. When something goes wrong, it would be nice to fail gracefully...

I wrote some tracking code to watch the accumulated jog input, and it looks like after one of these "backups" there will be a sudden, large jog offset of >7000, even though I barely touched the wheel. Even at a multiplier of ~0.1 is still a big instantaneous jog. I'm wondering if an enormous, sudden jog could actually result in the display and beat timers being wrong? Yes, the offset will all be in tiny increments well within the spec of the "jog" parameter, but... 7000/64 means it called setValue(...,'jog',-6.8) 109 times, and probably all within one tick of the clock timer, effectively an instantenous jog of -700 or so...

This is why I suspect packet duplication. Hmm.

[edit] SO many red herrings. There doesn't seem to be anything affecting the controller input resulting in duplicates. Removing all timers from my script makes no difference.

Things I am sure of

• Some sort of lag, visible in the USB output and sometimes the graphics (whether USB, controller fail, bad cord, or other I/O blocking interrupts) can cause one channel of Mixxx's internal engine to glitch
• Often the channel that glitches is not the one for which controller input is destined
• When it glitches I can see (in parallel tracks mode and via incorrect "beat flash" blinkies) that the graphics/usb timing are still correct but the audio is now offset, often 1/4 of a beat or more
• Stopping/restarting the track (via jog or pause/play) fixes the offset
• The glitch causes interesting output pitch stretching if "network clock" is in use
• Symptoms first appeared somewhere in version 2.3
• Does not result in buffer underflow count increases
• Can be reproduced with old or new rubberband

Obvious (?) conclusions

• it happens to one deck at a time, therefore it internal to the mixxx engine

Things I have tried

• app can/does set thread priorities
• Tried different USB ports
• There are no other USB devices
• large audio buffer
• Installed on a clean, fast system with no other apps on it. AMD/ALSA/Pipewire

Things I will try next

• Different waveform rendering engines
• USB cable?
• Exorcism?

[tekhedd]

It's GL. With a non-GL waveform I can not reproduce the random offsets. Also, the waveform display jumps around and flickers like a glitch video. It's fascinating and definitely not desirable. :}

I will chase specifics and update this comment. I need to confirm but I am pretty sure my old laptop also used GL, just different video drivers etc, for slightly more consistent results.

[edit] Nope, still happens, just not as often. Running in developer mode for the logging, this time got a bunch of "no read ahead log entries" messages when it happened. Hmmm.....

[edit2] If I engage keylock, i can no longer reproduce the problem. I can consistently reproduce the problem with keylock disabled, but both pitch and speed altered on both tracks. LOL and as I write this, I tried disengaging keylock on a pair of tracks that have happily stayed in sync for two minutes, touched a wheel, and it just bent off by at least a beat.

[edit3] It's not any of these things. I've tried a lot of things, from disabling pipewire to not using GL to tweaking the low latency kernel change the amount of jitter of the various clocks, to using the built in audio instead of MIDI devices (various controllers). I'm on linux so it's definitely "using the system clock for timing" but that's not supposed to cause major problems. I always have issues, eventually, if I engage the pitch streching engine but not with keylock enabled, eventaully the audio is offset from the delay, on some controller. Sometimes the offset is barely a pixel.

The waveform display is always flickery and jumpy, even though it's running at 60Hz supposedly.

When I run into the "no read ahead log entries" warniong, it's a guaranteed HUGE offset. I don't think this is the only cause, I do think it's a source of major jitter.

I can't find to find the jitter. I strongly suspect display driver issues, as this seems to be tied closely into the per-deck buffering. It's triggering some sort of "we can't detect this because it's a timer issue" problem in the mixxx engine. Weird.