[pulseaudio-discuss] Why only selected modules try to acquire realtime priority?

[marcin at saepia.net]

Hi,

I am trying to figure out why PulseAudio daemon drops a few samples
from time to time.

I got a few null sinks combined with each other by loopbacks. Then my
applications gather sound from their .monitors. Sounds simple.

I quickly came to idea that running PulseAudio in RT mode could help.
I encountered a lot of problems, because:
- my PA daemons are started at the boot time (but as normal users!)
and start-stop-daemon know nothing about /etc/security/limits.conf, so
I got troubles with setting limits for them without setting RT limits
for the whole system,
- PA daemon tries to communicate to rtkit and rtkit tries to
communicate to PolicyKit which becomes the next dependency for me
etc...

During the process I started to investigate pulseaudio & rtkit source
code and I found something strange.

e.g. combine module tries to acquire realtime priority during thread
initialization:

static void thread_func(void *userdata) {
    struct userdata *u = userdata;

    pa_assert(u);

    pa_log_debug("Thread starting up");

    if (u->core->realtime_scheduling)
        pa_make_realtime(u->core->realtime_priority+1);

    pa_thread_mq_install(&u->thread_mq);


while e.g. NULL sink doesn't:

static void thread_func(void *userdata) {
    struct userdata *u = userdata;

    pa_assert(u);

    pa_log_debug("Thread starting up");

    pa_thread_mq_install(&u->thread_mq);



What is the reason for that?

For me, it means that even if I solve all problems mentioned above, my
NULL sinks still wouldn't be using realtime scheduler policy?

Shouldn't it be fixed?

m.