most thread priorities are not set on Linux

[Be]

Looking at Mixxx's threads in htop, all of them have a priority of 20, except one which has a priority of -83. I presume the one with -83 is the audio callback thread. I added a line to the /etc/security/limits.d/95-jack.conf file that comes with the JACK package on Fedora to give my user permission to prioritize:
@jackuser - nice -20
I can renice threads after Mixxx starts so it is not a permission issue.

http://doc.qt.io/qt-4.8/qthread.html#setPriority :
The effect of the priority parameter is dependent on the operating system's scheduling policy. In particular, the priority will be ignored on systems that do not support thread priorities (such as on Linux, see http://linux.die.net/man/2/sched_setscheduler for more details).

[Daniel Schürmann (daschuer)]

Confirmed. I cannot believe that I have not noticed this before, when I worked with the engine thread priority :-/

Here my output:

daniel@daniel-530U3C-530U4C-532U3C:~$ ps -T -C19,_20 -o priority,ni,pcpu,pid,comm 2961
PRI NI %CPU PID COMMAND
 20 0 13.9 2961 mixxx
 20 0 0.0 2961 dconf worker
 20 0 0.0 2961 gdbus
 20 0 0.0 2961 gmain
 20 0 0.0 2961 EngineWorkerSch
 20 0 0.0 2961 EngineSideChain
 20 0 0.0 2961 VinylControlPro
 20 0 0.0 2961 CachingReaderWo
 20 0 0.0 2961 CachingReaderWo
 20 0 0.0 2961 CachingReaderWo
 20 0 0.0 2961 CachingReaderWo
 20 0 0.0 2961 CachingReaderWo
 20 0 0.0 2961 CachingReaderWo
 20 0 0.0 2961 CachingReaderWo
 20 0 0.0 2961 CachingReaderWo
 20 0 0.0 2961 CachingReaderWo
 20 0 0.0 2961 LibraryScanner
 20 0 0.0 2961 BrowseThread
 20 0 0.4 2961 AnalyzerQueue
 20 0 0.0 2961 Controller
 20 0 0.4 2961 VSyncThread
 20 0 0.0 2961 Controller
 20 0 0.0 2961 mixxx
-83 - 2.7 2961 mixxx

[Daniel Schürmann (daschuer)]

Here the same output + scheduler class:

http://man7.org/linux/man-pages/man7/sched.7.html

TS = SCHED_OTHER -> dynamic priority based on nice values NI
FF = SCHED_FIFO -> preempting all other

~$ chrt -m
SCHED_OTHER min./max. Priorität : 0/0
SCHED_FIFO min./max. Priorität : 1/99
SCHED_RR min./max. Priorität : 1/99
SCHED_BATCH min./max. Priorität : 0/0
SCHED_IDLE min./max. Priorität : 0/0

~$ ps -T -C19,_20 -o cls,priority,ni,pcpu,pid,comm 4059
CLS PRI NI %CPU PID COMMAND
 TS 20 0 6.3 4059 mixxx
 TS 20 0 0.0 4059 dconf worker
 TS 20 0 0.0 4059 gdbus
 TS 20 0 0.0 4059 gmain
 TS 20 0 0.0 4059 EngineWorkerSch
 TS 20 0 0.0 4059 EngineSideChain
 TS 20 0 0.0 4059 VinylControlPro
 TS 20 0 0.0 4059 CachingReaderWo
 TS 20 0 0.0 4059 CachingReaderWo
 TS 20 0 0.0 4059 CachingReaderWo
 TS 20 0 0.0 4059 CachingReaderWo
 TS 20 0 0.0 4059 CachingReaderWo
 TS 20 0 0.0 4059 CachingReaderWo
 TS 20 0 0.0 4059 CachingReaderWo
 TS 20 0 0.0 4059 CachingReaderWo
 TS 20 0 0.0 4059 CachingReaderWo
 TS 20 0 0.0 4059 LibraryScanner
 TS 20 0 0.0 4059 BrowseThread
 TS 20 0 0.0 4059 AnalyzerQueue
 TS 20 0 0.0 4059 Controller
 TS 20 0 0.4 4059 VSyncThread
 TS 20 0 0.0 4059 Controller
 TS 20 0 0.0 4059 mixxx
 FF -83 - 1.7 4059 mixxx

[Daniel Schürmann (daschuer)]

If it ain't broke, don't fix it

For my feeling we have no big issues with scheduling on Linux even though it does not work like it is set in code. We may facing scheduling issues on Windows when broadcasting https://bugs.launchpad.net/mixxx/+bug/1623620

My Linux issues are:
* Audio dropouts when storing analysis data on my eeePC. We need to analyses this issue, before we change anything here.
* jerking waveforms
* stalled GUI using mass track actions (Ctrl+A problem)

Dow we have other scheduling issues?

[-MK- (mk42)]

> Audio dropouts when storing analysis data on my eeePC. We need to analyses this issue, before we change anything here.

I don't know if we are able to do anything on that from mixxxs perspective, but:
Since I'm doing 'time-machine like' backups on my local hdd at runtime automatically, I get serious audio dropouts when running mixxx and that backup schedules at the same time.

The backup is running with lowest io prio, but probably loads the disk (it is writing to) so much, that mixxx can't get the audio files from that disk.

Mixxx isn't caching the playing tracks in memory, but getting the audio from disk on demand? Is there some kind of logic like 'I run out of audio-file buffer recently, maybe I should cache more than the current sample count'? Maybe that could help. Maybe there would be one single dropout, but after that mixxx would try to preload more data to have it availiable.

Maybe I should open another bug for that, but didn't know what terms to search for and found this one, maybe related, don't know if there are others pointing in the same direction...

[Daniel Schürmann (daschuer)]

The backup is running with lowest io prio, but probably loads the disk
(it is writing to) so much, that mixxx can't get the audio files from
that disk.

Do you have test data to verify this assumption? I think Mixxx will log
something if it suffers cache missed. (I need to verify it.)

Mixxx isn't caching the playing tracks in memory, but getting the audio
from disk on demand?

Mixxx does not cache the entire track, but enough to avoid such "HD in
used" issues. Maybe it can be improved for your use case though.

Are the tracks on the same pysical disk of you backup? What kind of disk do
you use and how is it connected?

Is the buffer underrun counter counting in Mixxx hardware preferences? Is
there a hint hat you are not running at Real Time Priority?

If yes, you issue is probably not related to the Mixxx read ahead cache. In
this case it is a common overload issue, or you suffer the known
concurrency issue when the track is analysed. Do you suffer dropouts, if no
analysis is running?

[Swiftb0y (swiftb0y)]

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