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=... [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