[pulseaudio-discuss] RFC: realtime prio for null and tunnel sinks? (Was Re: Why only selected modules try to acquire realtime priority?)

[Maarten Bosmans]

TL;DR; version: we should not be giving RT priorities without evidence
that they improve things.

2011/6/22 Colin Guthrie <gmane at colin.guthr.ie>:
> 'Twas brillig, and marcin at saepia.net at 20/06/11 17:20 did gyre and gimble:
>> And the next one, for tunnels.
>
> Both seem reasonable, but let me consult with others first.

Well, there seems to be no confirmation of the submitter that the
patches solve the problem of dropped samples. I'd much rather have him
try to setup his daemon to be able to acquire RT privs at all first
and seeing how that goes. Then, only if these patches provide any
benefit, they should be used.

The patch suggests using u->core->realtime_priority+1, which is higher
than what is used in the hardware modules. I don't think that's
appropriate.

> So guys, should these modules' threads look to be using RT prio?

Dunno actually. RT prio seems to be mostly used for threads
interfacing hardware in modules like alsa/oss/jack/waveout. Module
combine is a bit of an outlier in that regard, but as that module is
often used on top of hardware sinks, that could be reason enough.
(indeed, the +1 priority makes sense then)

null-sink is not layered on top of any hardware, so perhaps no
candidate for RT prio? In any case, there seems to be no precedent for
RT prio for network modules, so module-tunnel should also not have
that. Of course that makes sense, because the network modules already
handle latency with buffers >50ms, so scheduling priority should not
have much influence on that. (having said that, it is certainly worth
tinkering with the next time I dive into tunnels/rtp-streams etc.)

Maarten