Mixer worker threads do not have rtprio on Linux

[JohannesLorenz]

Calling

$ ps -o cmd,pid,pri,ni,rtprio -T $(pidof lmms)   # note: -T lists the threads
CMD                           PID PRI  NI RTPRIO
install/bin/lmms             8895  90   -     50
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   -      0
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   0      -
install/bin/lmms             8895  19   0      -

shows that currently only 1 thread (well, 2, for some reasons, but I run this on an >=4 core) has rtprio (realtime priority). Our worker threads do not have rtprio.

The desired behavior is that all worker threads have rtprio. E.g. if you add something like

if (jack_client_create_thread (client, &tid,
        jack_client_real_time_priority (client),
        jack_is_realtime (client),
        &worker_thread, NULL))
{
        fprintf (stderr, "failed to create realtime worker thread\n");
}

to the simple client example, you can see two rtprio threads in the ps output. Many thanks to @rgareus who found this solution.

This should be fixed for jack, and also for ALSA (in the way jack does it when it uses ALSA as backend).

Background:
Realtime priority lets the kernel schedule threads before any non realtime priority threads. If a thread that shall process audio does not have this priority, it may get interrupted ("preemption") by another thread, which can cause lag when you play music while your CPU is busy.

[PhysSong]

It seems like we have a relevant code in main.cpp, but that's for the main thread. We may do something similar for mixer worker threads.
FYI, you can get the limit of the RT priority by calling getrlimit with RLIMIT_RTPRIO, or from the Bash builtin ulimit -r. In my case, the default value was 95. It's also possible to use a binary search instead.

Related: QTBUG-3879

[PhysSong]

The Qt bug says Mac is not affected, but I can't confirm it. Windows have a different scheduling system, but I can't find bugs on Windows.

[x42]

MacOS/X mach kernel offers time-constraint scheduling. pthread_setschedparam isn't relevant for audio I/O. It's relatively straight forward to set a pthread's priority though:

thread_policy_set (pthread_mach_thread_np (thread_id), THREAD_TIME_CONSTRAINT_POLICY,...)

However if you use JACK, you should really use the libjack API to create helper threads.

[PhysSong]

@x42 Thanks for the information. We may try something similar to what JACK does.

[PhysSong]

This should be fixed for jack, and also for ALSA (in the way jack does it when it uses ALSA as backend).

However if you use JACK, you should really use the libjack API to create helper threads.

I strongly think that the fix should be independent of backends. I believe many users are using backends rather than JACK, and we should cover those cases.

[x42]

Keep in mind that if you use JACK, your application's internal helper rt-threads should not exceed the priority of jack's main process callback.

The straight forward solution is to have each backend provide the appropriate thread-start method. I don't think you can find a common, backend independent cross-platform solution for this.

[PhysSong]

I don't think you can find a common, backend independent cross-platform solution for this.

Do you have any reasons? No one can know if it's possible before really trying to implement it.

[x42]

On 7/28/19 4:07 AM, Hyunjin Song wrote: Do you have any reasons?

For ALSA your application is responsible for setting up thread priorities. With JACK your app is at the liberty of how a user configured jackd, on the upside JACK there's a nice [API](http://jackaudio.org/api/group__ClientThreads.html) MacOS mach thread priorities are vastly different. You basically set time constraints, not priority. Windows/ASIO is a whole different story as well, depends on what thread library you use and if the main callback polls and blocks, or runs directly in the IRQ callback.

No one can know if it's possible before really trying to implement it.

I've tried and succeeded for the most part writing the ALSA and Coreaudio backends of Ardour and am involved with ASIO/Portaudio backend and JACK as well https://github.com/Ardour/ardour/tree/master/libs/backends might come handy for inspiration. grep for `create_process_thread`.

[PhysSong]

https://github.com/Ardour/ardour/tree/master/libs/backends might come handy for inspiration.

Thank you for the references(https://github.com/Ardour/ardour/blob/master/libs/pbd/pthread_utils.cc as well). LMMS may need slightly different implementations, but that will definitely help. 👍

[JohannesLorenz]

The straight forward solution is to have each backend provide the appropriate thread-start method.

That's also what I would have proposed. E.g. AudioAlsa::startThread, AudioJack::startThread ...