On Tue, 31 Jul 2018 01:44:32 -0400, bill-auger wrote:
>aside from the new 'realtime' package, i would like to propose an
>audio-specific optimizations package of the sort that other av-centric
>distros commonly have - a package that contains goodies such as the
>'realTimeConfigQuickScan' and 'rtirq' scripts that will inform the
>user how best to optimize their hardware IRQ and PCI latency and such;
>and other suggestions from the linuxaudio wiki[1] that can be
>automated, such as selectively disabling and re-enabling unnecessary
>services (screensaver, printing, *ehem* pulse), a .jackdrc with
>smaller buffers than the default config, etc
>
>i did a side-by-side comparison with the analogous proaudio-settings
>optimization packages from each of parabola, kxstudio, and
>ubuntustudio - they are all nearly identical in what they accomplish;
>but AFAIK currently arch does not have an analogous package - here are
>some examples of what they do:
>
>--------
>
>using 'parabola-proaudio-settings'[2] as a reference:
>
># custom kernel parameters to sysctl.d folder
>/etc/sysctl.d/99-sysctl.conf
>  # By default, swap frequency defined by "swappiness" is set to 60.
> By reducing this number to 10, the system will wait much longer
> before trying to write to disk vm.swappiness = 10
>
>  # inotify watches for changes to files and reports them to
> applications requesting this information. When working with lots of
> audio data, a lot of watches will need to be kept track of, so they
> will need to be increased. fs.inotify.max_user_watches = 524288
>
>--------
>
># ensure the ALSA MIDI driver is loaded
>/etc/modules-load.d//alsamidi.conf
>  # If you want to use any MIDI hardware you need to ensure the ALSA
> MIDI driver is loaded snd_seq_midi
>
>--------
>
># recommended initial settings for jack
>/etc/jackdrc
>  /usr/bin/jackd -P89 -t2000 -dalsa -dhw:0 -r44100 -p256 -n2 -Xseq
>
>--------
>
># systemd service
># increase the highest requested RTC interrupt frequency (default is
>64 Hz) /etc/systemd/system/parabola-proaudio-settings.service
>/etc/parabola-proaudio-settings.sh
>  #!/bin/sh
>
>  echo 2048 > /sys/class/rtc/rtc0/max_user_freq
>  echo 2048 > /proc/sys/dev/hpet/max-user-freq
>  cpupower frequency-set -g performance
>  echo noop > /sys/block/sda/queue/scheduler
>
>--------
>
># extra virtual midi ports
>/etc/modprobe.d/snd-seq-dummy_16.conf
>  #Creates extra virtual midi ports
>  options snd-seq-dummy ports=8
>
>--------
>
>kxstudio 'kxstudio-default-settings'[3] has the following also:
>/etc/sysctl.d/10-kxstudio-sysctl-rules.conf
>  dev.hpet.max-user-freq = 2048
>
>--------
>
>ubuntustudio 'ubuntustudio-default-settings'[4] suggests that 3072 is
>a better value for dev.hpet.max-user-freq (although they have it
>commented out) #dev.hpet.max-user-freq=3072
>
>--------
>
>both kxstudio and ubuntustudio have the following also (this is the
>only concern that is specified in the new 'realtime'
>package): /lib/udev/rules.d/99-kxstudio-udev.rules /lib/udev/rules.d/40-timer-permissions.rules
>  KERNEL=="rtc0", GROUP="audio"
>  KERNEL=="hpet", GROUP="audio"
>
>--------
>
>
>[1]: https://wiki.linuxaudio.org/wiki/system_configuration
>[2]:
>https://git.parabola.nu/abslibre.git/tree/pcr/parabola-proaudio-settings?id=118a4df3e9af77664a701624e862ad8055fda98b
>[3]: https://github.com/KXStudio/KXStudio/tree/master/default-settings
>[4]: https://git.launchpad.net/ubuntustudio-default-settings/tree/

Hi,

I recommend against a package to check esoteric settings. Is it tested
that the swappiness value plays a role on a modern machine? How much RAM
might an averaged pro-audio machine has got? If swapping should happen,
how much is performance loss, if the swap is on a SATA3 SSD? Wouldn't
it be more likely, that on a reasonable pro-audio machine page table
isolation could have some impact on performance? How about the 'nopti'
boot option? I guess a user should test such options, if there should
be performance issues. If a user doesn't experience an issue, there is
no need to even test, if such options could improve something, let
alone to change default settings for no reason at all. As for pulse
audio, this doesn't belong on a pro-audio machine, period! If for
somebody pulseaudio is useful on a pro-audio machine, the Arch Linux
user likely will be able to find out, how to manage usage of a pro-audio
sound server in combination with a soundserver, that is not intended for
pro-audio usage. Why depending on a tool such as 'cpupower' that is not
needed to set CPU frequency scaling to 'performance'? Apart from bugs
that could happen and cause snd_seq_midi to load, there is no need at
all, to ensure that it gets loaded. How could 44,1KHz be a recommended
sample frequency for a pro-audio environment, while most pro-sumer and
professional audio devices work best at 48KHz? And so on and so
forth... Don't get me wrong, a user could experience issues and it
could make sense to test something. On my old machine it was helpful to
unbind USB ports. On my new machine I still get better results, even if
a port is used that shares an IRQ with another device. On some machines
it could be useful to test different PCI{,e} slots. On some machines it
doesn't matter at all, in the end different slots anyway could be quasi
one split slot. IMO tuning a pro-audio computer depends on way to much
individual contingencies. It doesn't make sense even to try to allow
for all possibilities. Assuming I should experience too much MIDI
jitter on my new machine were until now MIDI jitter wasn't an issue,
since I didn't use it for tasks where MIDI jitter could be an issue, I
perhaps would test if increasing /proc/sys/dev/hpet/max-user-freq from
the default 64 to another value. OTOH how much valid information coukld
we expect from the Rosegarden Wiki mentioned by the Linux audio org
Wiki of your link, if they mention 'audio nice -15' as
a /etc/security/limits.conf value. The 'nice' value isn't simply
outdated, it never was correct to assume that a nice value has got any
real-time impact at all. 'rtc0' and 'CONFIG_HZ_1000=y' isn't wrong
information, but it's a little bit outdated. Keep in mind that
proprietary audio software for Linux sometimes assumes SSE3 support,
see https://www.bitwig.com/en/support/faq.html . We shouldn't follow
the approach of each user-friendly distro to provide unreasonable
supposedly optimisation.

2 Cents,
Ralf