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

[marcin at saepia.net]

And the next one, for tunnels.

m.

2011/6/20 marcin at saepia.net <marcin at saepia.net>:
> Great! Please, could you commit the attached patch?
>
> m.
>
>
>
> 2011/6/20 Colin Guthrie <gmane at colin.guthr.ie>:
>> 'Twas brillig, and marcin at saepia.net at 20/06/11 14:55 did gyre and gimble:
>>> 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?
>>
>> Probably this is just because no one has had a reason for this
>> before.... it's certainly worth thinking about if it does solve your
>> problem.
>>
>> Col
>>
>>
>>
>> --
>>
>> Colin Guthrie
>> gmane(at)colin.guthr.ie
>> http://colin.guthr.ie/
>>
>> Day Job:
>>  Tribalogic Limited [http://www.tribalogic.net/]
>> Open Source:
>>  Mageia Contributor [http://www.mageia.org/]
>>  PulseAudio Hacker [http://www.pulseaudio.org/]
>>  Trac Hacker [http://trac.edgewall.org/]
>>
>> _______________________________________________
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: use_rt_in_tunnel.patch
Type: text/x-patch
Size: 359 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110620/97d81008/attachment.bin>