And the next one, for tunnels.
m.
2011/6/20 [email protected] <[email protected]>:
> Great! Please, could you commit the attached patch?
>
> m.
>
>
>
> 2011/6/20 Colin Guthrie <[email protected]>:
>> 'Twas brillig, and [email protected] 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
>> [email protected]
>> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>
>
--- src2/modules/module-tunnel.c 2011-06-20 18:03:41.446519001 +0200
+++ src/modules/module-tunnel.c 2011-06-20 18:19:36.139253066 +0200
@@ -694,6 +694,9 @@
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);
for (;;) {
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
