<div dir="ltr"><div>From my recent experience benchmarking the DAW I'm working on under Arch (ossia-score-git, please check it out ! :D), disabling the intel sleep states and basically every idling stuff (cpupower idle-set -D 0) had a muuuuch greater impact on jitter than anything else I could do.</div><div><br></div><div>> How could 44,1KHz be a recommended<br>
sample frequency for a pro-audio environment, while most pro-sumer and<br>
professional audio devices work best at 48KHz? </div><div><br></div><div>Do you have a source for this ? if anything, unless you work primarily in motion picture sound & music, most sample libraries are recorded at 44100 so you will get resampling fairly often if you're not on 44100.</div><div><br></div><div>Best</div><div>Jean-Michaël<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><div><font color="#783f04"><br></font></div><div><font face="arial, helvetica, sans-serif" size="2" color="#134f5c">-------</font></div><font face="arial, helvetica, sans-serif" size="2" color="#134f5c">Jean-Michaël Celerier</font><div><font face="arial, helvetica, sans-serif" size="2" color="#134f5c"><a href="http://www.jcelerier.name" target="_blank">http://www.jcelerier.name</a></font></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jul 31, 2018 at 10:37 AM, Ralf Mardorf <span dir="ltr"><<a href="mailto:ralf.mardorf@alice-dsl.net" target="_blank">ralf.mardorf@alice-dsl.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 31 Jul 2018 01:44:32 -0400, bill-auger wrote:<br>
>aside from the new 'realtime' package, i would like to propose an<br>
>audio-specific optimizations package of the sort that other av-centric<br>
>distros commonly have - a package that contains goodies such as the<br>
>'realTimeConfigQuickScan' and 'rtirq' scripts that will inform the<br>
>user how best to optimize their hardware IRQ and PCI latency and such;<br>
>and other suggestions from the linuxaudio wiki[1] that can be<br>
>automated, such as selectively disabling and re-enabling unnecessary<br>
>services (screensaver, printing, *ehem* pulse), a .jackdrc with<br>
>smaller buffers than the default config, etc<br>
><br>
>i did a side-by-side comparison with the analogous proaudio-settings<br>
>optimization packages from each of parabola, kxstudio, and<br>
>ubuntustudio - they are all nearly identical in what they accomplish;<br>
>but AFAIK currently arch does not have an analogous package - here are<br>
>some examples of what they do:<br>
><br>
>--------<br>
><br>
>using 'parabola-proaudio-settings'[<wbr>2] as a reference:<br>
><br>
># custom kernel parameters to sysctl.d folder<br>
>/etc/sysctl.d/99-sysctl.conf<br>
>  # By default, swap frequency defined by "swappiness" is set to 60.<br>
> By reducing this number to 10, the system will wait much longer<br>
> before trying to write to disk vm.swappiness = 10<br>
><br>
>  # inotify watches for changes to files and reports them to<br>
> applications requesting this information. When working with lots of<br>
> audio data, a lot of watches will need to be kept track of, so they<br>
> will need to be increased. fs.inotify.max_user_watches = 524288<br>
><br>
>--------<br>
><br>
># ensure the ALSA MIDI driver is loaded<br>
>/etc/modules-load.d//<wbr>alsamidi.conf<br>
>  # If you want to use any MIDI hardware you need to ensure the ALSA<br>
> MIDI driver is loaded snd_seq_midi<br>
><br>
>--------<br>
><br>
># recommended initial settings for jack<br>
>/etc/jackdrc<br>
>  /usr/bin/jackd -P89 -t2000 -dalsa -dhw:0 -r44100 -p256 -n2 -Xseq<br>
><br>
>--------<br>
><br>
># systemd service<br>
># increase the highest requested RTC interrupt frequency (default is<br>
>64 Hz) /etc/systemd/system/parabola-<wbr>proaudio-settings.service<br>
>/etc/parabola-proaudio-<wbr>settings.sh<br>
>  #!/bin/sh<br>
><br>
>  echo 2048 > /sys/class/rtc/rtc0/max_user_<wbr>freq<br>
>  echo 2048 > /proc/sys/dev/hpet/max-user-<wbr>freq<br>
>  cpupower frequency-set -g performance<br>
>  echo noop > /sys/block/sda/queue/scheduler<br>
><br>
>--------<br>
><br>
># extra virtual midi ports<br>
>/etc/modprobe.d/snd-seq-<wbr>dummy_16.conf<br>
>  #Creates extra virtual midi ports<br>
>  options snd-seq-dummy ports=8<br>
><br>
>--------<br>
><br>
>kxstudio 'kxstudio-default-settings'[3] has the following also:<br>
>/etc/sysctl.d/10-kxstudio-<wbr>sysctl-rules.conf<br>
>  dev.hpet.max-user-freq = 2048<br>
><br>
>--------<br>
><br>
>ubuntustudio 'ubuntustudio-default-<wbr>settings'[4] suggests that 3072 is<br>
>a better value for dev.hpet.max-user-freq (although they have it<br>
>commented out) #dev.hpet.max-user-freq=3072<br>
><br>
>--------<br>
><br>
>both kxstudio and ubuntustudio have the following also (this is the<br>
>only concern that is specified in the new 'realtime'<br>
>package): /lib/udev/rules.d/99-kxstudio-<wbr>udev.rules /lib/udev/rules.d/40-timer-<wbr>permissions.rules<br>
>  KERNEL=="rtc0", GROUP="audio"<br>
>  KERNEL=="hpet", GROUP="audio"<br>
><br>
>--------<br>
><br>
><br>
>[1]: <a href="https://wiki.linuxaudio.org/wiki/system_configuration" rel="noreferrer" target="_blank">https://wiki.linuxaudio.org/<wbr>wiki/system_configuration</a><br>
>[2]:<br>
><a href="https://git.parabola.nu/abslibre.git/tree/pcr/parabola-proaudio-settings?id=118a4df3e9af77664a701624e862ad8055fda98b" rel="noreferrer" target="_blank">https://git.parabola.nu/<wbr>abslibre.git/tree/pcr/<wbr>parabola-proaudio-settings?id=<wbr>118a4df3e9af77664a701624e862ad<wbr>8055fda98b</a><br>
>[3]: <a href="https://github.com/KXStudio/KXStudio/tree/master/default-settings" rel="noreferrer" target="_blank">https://github.com/KXStudio/<wbr>KXStudio/tree/master/default-<wbr>settings</a><br>
>[4]: <a href="https://git.launchpad.net/ubuntustudio-default-settings/tree/" rel="noreferrer" target="_blank">https://git.launchpad.net/<wbr>ubuntustudio-default-settings/<wbr>tree/</a><br>
<br>
</div></div>Hi,<br>
<br>
I recommend against a package to check esoteric settings. Is it tested<br>
that the swappiness value plays a role on a modern machine? How much RAM<br>
might an averaged pro-audio machine has got? If swapping should happen,<br>
how much is performance loss, if the swap is on a SATA3 SSD? Wouldn't<br>
it be more likely, that on a reasonable pro-audio machine page table<br>
isolation could have some impact on performance? How about the 'nopti'<br>
boot option? I guess a user should test such options, if there should<br>
be performance issues. If a user doesn't experience an issue, there is<br>
no need to even test, if such options could improve something, let<br>
alone to change default settings for no reason at all. As for pulse<br>
audio, this doesn't belong on a pro-audio machine, period! If for<br>
somebody pulseaudio is useful on a pro-audio machine, the Arch Linux<br>
user likely will be able to find out, how to manage usage of a pro-audio<br>
sound server in combination with a soundserver, that is not intended for<br>
pro-audio usage. Why depending on a tool such as 'cpupower' that is not<br>
needed to set CPU frequency scaling to 'performance'? Apart from bugs<br>
that could happen and cause snd_seq_midi to load, there is no need at<br>
all, to ensure that it gets loaded. How could 44,1KHz be a recommended<br>
sample frequency for a pro-audio environment, while most pro-sumer and<br>
professional audio devices work best at 48KHz? And so on and so<br>
forth... Don't get me wrong, a user could experience issues and it<br>
could make sense to test something. On my old machine it was helpful to<br>
unbind USB ports. On my new machine I still get better results, even if<br>
a port is used that shares an IRQ with another device. On some machines<br>
it could be useful to test different PCI{,e} slots. On some machines it<br>
doesn't matter at all, in the end different slots anyway could be quasi<br>
one split slot. IMO tuning a pro-audio computer depends on way to much<br>
individual contingencies. It doesn't make sense even to try to allow<br>
for all possibilities. Assuming I should experience too much MIDI<br>
jitter on my new machine were until now MIDI jitter wasn't an issue,<br>
since I didn't use it for tasks where MIDI jitter could be an issue, I<br>
perhaps would test if increasing /proc/sys/dev/hpet/max-user-<wbr>freq from<br>
the default 64 to another value. OTOH how much valid information coukld<br>
we expect from the Rosegarden Wiki mentioned by the Linux audio org<br>
Wiki of your link, if they mention 'audio nice -15' as<br>
a /etc/security/limits.conf value. The 'nice' value isn't simply<br>
outdated, it never was correct to assume that a nice value has got any<br>
real-time impact at all. 'rtc0' and 'CONFIG_HZ_1000=y' isn't wrong<br>
information, but it's a little bit outdated. Keep in mind that<br>
proprietary audio software for Linux sometimes assumes SSE3 support,<br>
see <a href="https://www.bitwig.com/en/support/faq.html" rel="noreferrer" target="_blank">https://www.bitwig.com/en/<wbr>support/faq.html</a> . We shouldn't follow<br>
the approach of each user-friendly distro to provide unreasonable<br>
supposedly optimisation.<br>
<br>
2 Cents,<br>
Ralf<br>
</blockquote></div><br></div>