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
