Here we enumerate all of the areas where Mixxx can be optimized, roughly in order of importance. The more things we can complete on this list, the more machines Mixxx can run on, and the larger our user base.
The most important thread is the audio callback thread. If this misses its deadline (the latency period,) pops and clicks can be heard in the output. As a result, it needs real-time priority, preferably with a hard deadline matching the latency period. (And we need to make sure it runs as succinctly and efficiently as possible so it can complete its work within the latency period (which can ideally be as low as 1ms.) Taking any longer would be shooting itself in the foot.)
Note that there are currently many places the callback thread does or can call QMutex::lock(), which *will* block until the mutex becomes free for locking. This cannot happen in the callback thread, it almost guarantees a missed deadline (and consequently an underrun) at some point in the future, even if the triggering conditions are quite rare (but with threads, anything is possible). Here's a list (add if you find another, I'll add the callstacks when I'm more awake):
Any locking of mutexes done in the callback _must_ be done with QMutex::tryLock(), which does not block if the mutex is already locked. Program logic will need to change accordingly.
TO DO: Ensure the audio callback thread gets real-time priority when run as a regular user. - RJ discovered that Mixxx's requests for real-time priority on this thread are having no effect. Running as a regular user on Linux shows that the priority range is from 0 to 0, and as root from 1 to 99, but it is set to 1 (the lowest) by default. However, calling
setPriority(QThread::TimeCriticalPriority) (while running as root) does result in priority escalation.
(xwax has been able to solve this problem on Linux. See the
rig_realtime function in rig.c.)
First, are threads evil? The gist is that concurrent events that threads cause are wildly unpredictable and are therefore extremely difficult to work with even in simple cases since there are an exponential number of possible race conditions. The paper suggests alternative proven methods that would work better and are easier to work with especially in a user-facing application like Mixxx.
Next, read this Qt blog post regarding proper use of QThread. (It's my impression that we are in fact doing what he says not to do which is the reason for all the threads we have.)
Mixxx's current thread list.
As Mixxx's functionality grows and it's extended to work with arbitrary numbers of resources, we need to consolidate the work to handle each resource into a single thread. This currently needs to be done for:
Stepping back for a moment, what are the goals we're trying to reach? As I see it, we want anything user-facing to respond in a hard-limited amount of time. This includes:
Of course audio needs to be processed as fast as possible, but that varies based on the user's machine capabilities, so we have the latency slider. So the audio needs to “refresh” within the latency period. I suggest that 30fps is an acceptable refresh rate for anything visual (GUI and MIDI output,) which translates to 33.3 (repeating) milliseconds. We could have a “visual latency” slider denoted in fps as well to help under-powered machines. Then we'd have a process() function for each of these user-facing items that did nothing more than the bare minimum to update their respective areas from a current snapshot of MixxxControls. (E.g. the Audio::process() would do the real-time processing (FX, EQ, etc.) of the current latency buffer, GUI::process() would simply repaint the display, and MIDI::process() would send queued messages to and receive queued messages from the controller(s).) These must finish before the applicable latency period. If they can't, they must defer additional work (or just abort in the case of audio) until the next period. (And the user will want to adjust the slider up at that point.)
So I suggest two user-facing threads: an audio one at real-time priority and a GUI+MIDI update one (Qt's main thread) at high or normal priority. Each would set up a timer to fire every applicable latency period that simply called the respective process() functions. (It would be interesting to automatically adjust the sliders up (if the user chooses) if anything times out, i.e. another timer event arrives before process() has returned.)
Then have a single additional thread at normal (if GUI+MIDI is high) or lower-than-normal priority for everything else (where the MixxxControls are actually updated,) but here too each sub-system needs a process() function that returns as quick as it can. This means any long CPU-hogging operations (like track analysis, DB and file I/O, script engines) must be split into time slices.
(Anything found that wastes CPU time should be listed here)
// Stopped. Wheel, jog and scratch controller all scrub through audio. rate=(wheel->get()*40.+m_pControlScratch->get()+m_jogfilter->filter(m_pJog->get()))*baserate; //*10.; m_pJog->set(0.);
(Please list all time-critical code sections/functions here to be considered for assembly language reimplementation.)
(Anything that wastes memory by inefficient storage (where unnecessary) or leaks goes here)