https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.novell.com/show_bug.cgi?id=579932#c153
--- Comment #153 from Mike Galbraith
(In reply to comment #149)
If it's _not_ one of those crippled up hpet inflicted boxen (can't help at all there), I'd fire up tracer with wakeup_rt tracer and see what's going on if an rt task doesn't hit the CPU in short order. A full ms wakeup latency is definitely not considered to be in short order for an rt task ;-)
Ok.
You can forget that 100us constraint though, it's not really achievable under load with a non-rt kernel, and certainly not when you add tracing overhead on top. If THP is on, turn that off (I traced
600us held in kernel by that in NOPREEMPT kernel iirc), and run some normal load where sound doesn't play well.
Well, I'd still like to stay within the reasonable here since it is the stock kernel and we're talking about audio (I'm not saying RT folk is unreasonable :-)). If it can stomach higher latencies without becoming noticeable, then we're fine.
Audio playback is generally so heavily buffered that it's pretty boring, can and must tolerate a LOT of scheduling latency because it's done by plain old SCHED_OTHER tasks that have no idea or control over when they'll be preempted, or for how long. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.