Pipewire: QThread::setPriority fails

[daschuer]

Bug Description

With Mixxx 2.3.4 I see the following warning in the mixxx.log

Warning []: QThread::setPriority: Cannot determine scheduler priority range

It comes from Qt https://github.com/qt/qtbase/blob/5.12.5/src/corelib/thread/qthread_unix.cpp#L827
And indicates that the command QThread::currentThread()->setPriority(QThread::TimeCriticalPriority);
fails. There is already a comment that this call has no effect, but why does this obscure warning appear?

Version

2.3.4

OS

Linux

[daschuer]

The issue is that sched_get_priority_max() returns -1
It is called with policy 0x40000001 which is SCHED_RESET_ON_FORK | SCHED_FIFO;

It looks like a QT bug, because the sched_get_priority_max() does not support that flag.
If I mask that away using GDB, it works flawlessly.

The issue has been introduced with pipewire, in case of ALSA this flag is not set

[daschuer]

@robbert-vdh Since you are the author of the related Pipewire code, can you have a look and verify/recommend how Mixxx should behave?

[daschuer]

I have also filed a Qt bug: https://bugreports.qt.io/browse/QTBUG-112720

[robbert-vdh]

I'm assuming this happens here, right?

mixxx/src/soundio/sounddeviceportaudio.cpp

Lines 885 to 889 in 49dda98

	// Turn on TimeCritical priority for the callback thread. If we are running
	// in Linux userland, for example, this will have no effect.
	if (!m_bSetThreadPriority) {
	QThread::currentThread()->setPriority(QThread::TimeCriticalPriority);
	m_bSetThreadPriority = true;

The audio thread on Linux should be set to SCHED_FIFO/SCHED_FIFO | SCHED_RESET_ON_FORK with a priority that's somewhere between 60 and 90 depending on the allowed priority ranges (some USB devices by default get assigned a priority in the 50s with some system configs). As already documented in the code I quoted, the setpriority call probably won't do much on Linux. Either the thread is already set up correctly because of the audio server, or it's still set to the SCHED_OTHER policy in which case the call also wouldn't do anything. I have no idea if PortAudio's ALSA backend sets up realtime scheduling correctly (easy to check), but with JACK/PipeWire the audio server will have already set up the audio callback thread for you.

So since this call won't do anything useful, it probably also won't hurt to just skip it on Linux. May be worth replacing it with a one time warning that makes sure that (sched_getscheduler(0) & SCHED_FIFO) != 0) on Linux though.

[daschuer]

Cool thank you for the insights. I think I will go ahead and issue a PR for this once I find time.