https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.novell.com/show_bug.cgi?id=579932#c155
--- Comment #155 from Mike Galbraith
(In reply to comment #153)
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.
Yep, and reportedly it still causes degradation in audio performance. I'd be nice to have a good reproducer for this observation though ...
My little Toshiba Satellite lappy is blessed with a tsc that stops, so uses hpet clocksource (unless I boot processor.max_cstate=1). Audio playback is peachy, as is playing a DVD serfing etc, both with and without a competing load, ie w. wo. entering C-[23]. read_hpet() is pretty horrible kernel overhead wise, but everything works just fine with openSUSE-12.3 kernel or mainline. Hohum.. my hpet is not the right flavor of trash. -- 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.