On 09/11/20 12:14, John Dias wrote: > I agree that the rt-softirq interaction patches are a gross hack (and I > wrote the original versions, so it's my grossness). The problem is that > even a 1ms delay in executing those low-latency audio threads is enough to > cause obvious glitching in audio under very real circumstances, which is > not an acceptable user experience -- and some softirq handlers run for >1ms > on their own. (And 1ms is a high upper bound, not a median target.)
AFAIK professional audio apps have the toughest limit of sub 10ms. 120MHz screens impose a stricter limit on display pipeline too to finish its frame in 8ms. 1ms is too short and approaches PREEMPT_RT realm. Is it possible to expand on the use case here? What application requires this constraint? Thanks -- Qais Yousef
