search

mixxxdj / mixxx

Mixxx is Free DJ software that gives you everything you need to perform live mixes.
http://mixxx.org
Other
4.45k stars 1.27k forks source link

most thread priorities are not set on Linux #8687

Open mixxxbot opened 2 years ago

mixxxbot commented 2 years ago

Reported by: Be-ing Date: 2016-11-12T22:45:06Z Status: Confirmed Importance: High Launchpad Issue: lp1641359

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).

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2016-11-13T11:34:22Z

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
mixxxbot commented 2 years ago

Commented by: daschuer Date: 2016-11-13T12:22:44Z

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
mixxxbot commented 2 years ago

Commented by: daschuer Date: 2016-11-13T15:53:03Z

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:

Dow we have other scheduling issues?

mixxxbot commented 2 years ago

Commented by: mk42 Date: 2017-03-11T07:45:21Z

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...

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2017-03-11T10:43:16Z

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?