[arch-proaudio] 'proaudio-settings' package

[Joakim Hernberg]

On Tue, 31 Jul 2018 13:43:42 +0200
Ralf Mardorf <ralf.mardorf at alice-dsl.net> wrote:

> 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