[arch-proaudio] 'proaudio-settings' package

Tue Jul 31 09:01:32 UTC 2018

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

> 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?

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.

Best
Jean-Michaël

-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Jul 31, 2018 at 10:37 AM, Ralf Mardorf <ralf.mardorf at alice-dsl.net>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.archlinux.org/pipermail/arch-proaudio/attachments/20180731/67290fe3/attachment.html>