On Tue, 31 Jul 2018 13:43:42 +0200
Ralf Mardorf
Or if most of us agree with my point of view, that audio set-ups differ way too much and there could be too many pitfalls, when changing (upstream) defaults to values, that might improve rt performance, but that not necessarily are needed to get a good rt performance.
I have to agree with you Ralf B) I am of the firm belief, that as a benchmark you ought to do the following for an audio machine: 1. Install a realtime kernel (properly configured with highres timers/etc), this makes the kernel itself preemptable, which leads to lower kernel scheduling latency. 2. Set a high priority for the thread servicing the soundcard/usb hub interrupt. 3. Make sure that your user has memlock and rtprio. Of course there are a lot of other changes one can do. Like increase file/ionotify handles, etc. Still IMO there is so much (for lack of a better term), old info/confusion/voodoo/etc, when you google something regarding linux audio. Some people might even have to trouble shoot their machine, a bios or wifi driver/hw could cause xruns. Other people will probably have a no problems at all after taking care of the 3 points, or even just with a low latency kernel which is also preemptive, just not for the kernel itself. Other people will have to keep their CPU out of sleeping states. On my desktop sandybridge running with pstate it doesn't seem to matter, on my laptop haswell (pstate) using the /dev/cpu_dma_latency interface results in significantly lower JACK dsp load :) Personally I think the addition of the realtime group is a good thing, and that we shouldn't apply loads of tuning to the system. The rest would possibly be better for an audio tuning wiki article. Of course YMMW :) -- Joakim