Comment 7 for bug 1642105

Daniel's right -- the Mixxx RT thread (assuming it's actually getting
marked RT, which it should by default on Ubuntu Studio) should never get
pre-empted by another Mixxx thread, so this is likely priority inversion.

Our use of signals/slots in the engine means we're constantly locking
global Qt mutexes (for example
http://code.qt.io/cgit/qt/qt.git/tree/src/corelib/kernel/qcoreapplication.cpp#n1360
is
locked on every emit() that is queued) and allocating memory (emitting a
queued signal calls malloc). If any other thread is pre-empted while
holding that mutex or allocating memory then the engine thread will block.

On Wed, Nov 16, 2016 at 1:41 PM Daniel Schürmann <email address hidden>
wrote:

> >From the scheduler theory, a real-time thread should not be suspended by
> any other thread.
> It should run very deterministic and independent from what else is going
> on in the machine.
>
> Since this seams to be not the case, we may have still locking calls, or
> it is an CPU frequency scaling issue, or it is just some extra engine
> work wen loading a track.
>
> Your AMD A4-3300M has a frequency scaling 1900 - 2500 MHz.
> If I read it right, it lowers the frequency to 1900 MHz if both cores are
> used. This is most likely the case if both cores are used.
>
> This issue become worth when we consider hyper-threading (not the case
> here)
>
> It could be interesting to lock the cpu clock on 1900 MHz and check how
> the issue behaves than.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1642105
>
> Title:
> Buffer underflow when adding a track
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1642105/+subscriptions
>