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

On Tue, 31 Jul 2018 01:44:32 -0400, bill-auger wrote: 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

On Tue, 31 Jul 2018 11:01:32 +0200, Jean-Michaël Celerier wrote:

Do you have a source for this ?

Yesno! Actually I'm the source, since I worked as a professional audio engineer for e.g. Brauner Microphones, Werner Nekes and other. However, perhaps you expect something as the below quoted Wikis: "Sampling rate 48,000 Hz The standard audio sampling rate used by professional digital video equipment such as tape recorders, video servers, vision mixers and so on. This rate was chosen because it could reconstruct frequencies up to 22 kHz and work with 29.97 frames per second NTSC video - as well as 25 frame/s, 30 frame/s and 24 frame/s systems. With 29.97 frame/s systems it is necessary to handle 1601.6 audio samples per frame delivering an integer number of audio samples only every fifth video frame.[9] Also used for sound with consumer video formats like DV, digital TV, DVD, and films. The professional Serial Digital Interface (SDI) and High-definition Serial Digital Interface (HD-SDI) used to connect broadcast television equipment together uses this audio sampling frequency. Most professional audio gear uses 48 kHz sampling, including mixing consoles, and digital recording devices." - https://en.wikipedia.org/wiki/Sampling_(signal_processing)#Sampling_rate "To avoid aliasing, the input to an ADC must be low-pass filtered to remove frequencies above half the sampling rate. This filter is called an anti-aliasing filter, and is essential for a practical ADC system that is applied to analog signals with higher frequency content." - https://en.wikipedia.org/wiki/Analog-to-digital_converter#Sampling_rate An audio device might come with a filter optimized for 48KHz usage.

31.07.2018 11:01 Jean-Michaël Celerier:

From my recent experience benchmarking the DAW I'm working on under Arch (ossia-score-git, please check it out ! :D),

ossia-score-git has /usr/bin/score and /usr/bin/score.sh . Would you please consider renaming that to ossia-score ? 1) I always find it confusing if the package name is not the binary name 2) score is a very generic term. yours, hgn

31.07.2018 11:01 Jean-Michaël Celerier: From my recent experience benchmarking the DAW I'm working on under Arch (ossia-score-git, please check it out ! :D), ossia-score-git has /usr/bin/score and /usr/bin/score.sh . Would you please consider renaming that to ossia-score ? 1) I always find it confusing if the package name is not the binary name 2) score is a very generic term. yours, hgn

On Tue, 2018-07-31 at 10:37 +0200, Ralf Mardorf wrote:

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

PS: I should clarify this. Try to find a CPU with SSE3, that doesn't provide hpet. My old x86_64 machine already had a hpet, by only providing SSE2. While most Linux distros dropped x86 packages, we shouldn't care about settings, that are irrelevant for most, if not all x86_64 computers. Even my new computer is more or less the most inexpensive computer you could build yourself, for example using a cheap and discontinued CPU. $ hwinfo --cpu | grep Model | sort -u Model: 6.60.3 "Intel(R) Celeron(R) CPU G1840 @ 2.80GHz" I suspect that most users own computers, that are much more expensive, powerful, modern, than mine computer, there are unlikely many users still using less powerful, very old computers. It seems to be more common, that somebody does use the latest and greatest Intel or AMD setup connected to an around 10,-€/$ cheap AliExpress USB interface.

On Tue, 31 Jul 2018 12:47:33 +0200, SpotlightKid wrote:

Ralf, may I ask you, as a courtesy to others:

* do not full quote.

Hi, this happened by accident. You might have noticed that I'm usually not quoting full text, at least not without inline replying. You might also have noticed, that I'm not the only one who quoted everything during this thread ;).

* use the frickin return key to divide your posts into some paragraphs.

Usually I also try to do this, it anyway happens automatically when doing inline reply. However, sometimes I simply type a reply very fast and could miss to add paragraphs, while being in a hurry and try to keep all notes in mind. Back to the topic: I wonder if most of us prefer such a package and if so, if there are advantages I might have missed? 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. A simple example, keep in mind, to use CPU frequency scaling governor 'performance' indeed could be required for some audio work, at least on some machines, but it might not be needed for all kinds of pro-audio usage, while charge of a battery could be important for some kind of pro-audio work. It's not that easy to find universal optimized settings that are useful for most kinds of pro-audio usage, as well as useful for many hardware set-ups. I might be mistaken, but some 'improvements' even seems to be esoteric, or at best useful for hardware, that isn't supported by Arch Linux repositories. We easily could end up with a package providing improved defaults values, as well as counter-productive values. If at all, a script with everything commented out might be helpful and a user could read the scripts comments and then uncomment what could be useful. Keep in mind that the user-friendly distros mentioned by the OP follow a policy, where e.g. each service provided by package is automatically enabled. Those distros by default autostart tons of unneeded software that need resources. If you install an Arch Linux package to get some software, but you don't want that a daemon you don't need, that also is provided by this package, gets autostarted, you have to do nothing. So called 'user-friendliness' ships with pitfalls. Regards, Ralf

i did not intend to imply that those were the complete settings and precise values to be used - those were just examples of some things that every a/v distro i have ever used does - today arch makes no optimizations of any kind; so it seems to me that it probably should, if arch-proaudio is to be considered as a viable alternative to the tailored a/v production distros - or else why bother? - i assumed that was the goal of this group - so far, all of 'arch-proaudio' is nothing more than a meta-package of suggested programs, yes? - if that is the limit of the effort, i say that is hardly worth doing the argument against and optimizations package seems to be mainly, that the high-powered machines that arch targets do not need to be optimized; or that the user will know how to tune their system without assistance or advice - if so, then surely they know how to install jack and ardour without a meta-package; so what exactly is this all about? - what is unreasonable IMHO, is the assumption that all arch users know their system inside and out; and that all arch users have computers so powerful that no optimizations are necessary perhaps some of those recommendations could be considered as out-dated; but if so, then isnt it better to experiment and update the recommendations and the system scanner script (and the linuxaudio wiki, and the arch wiki) rather than dismiss, out of hand, that some recommendations should exist? if people are so convinced that todays computers are so much different than the ones originally targeted by those optimization packages, and so those generic optimization are sub-optimal or inapplicable today; then that itself proves that this area of knowledge has been neglected for too long and is past due for some attention, because i have never seen any such conflicting "modern" advice anywhere until reading this today i am not at all suggesting to blindly "follow" other distros - indeed those optimizations packages have been around for some years and their particular optimizations may be most useful for, what are today older machines; but that does not make those settings unreasonable for those machines, nor harmful for new machines - i am more suggesting taking the "lead" here by putting some effort into determining what are the best recommendations for the fat machines that archlinux targets; and to offer that as an option in addition to the "classic" settings that older machines will benefit from - maybe it would be found that there are no generic settings for todays new computers, and all tweaks must be done by a skilled hand - that would still be a good reason for some updated documentation or tutorial and an updated system scanner script to assist those lacking a full neck-beard as for the older machines, i find it to be quite unfortunate that arch has kicked users of those older machines to the curb - those machines still exist in large numbers and are quite adequate for most audio tasks; and parabola (and archlinux32) continues to support them indefinitely - not to mention the ARM and other inexpensive hobby platforms; which are also adequate for most audio tasks and are increasing in number - in other words, i am going to maintain this package anyways - i am attempting here to make it a group effort to determine what exactly are some recommended defaults for an intel/AMD audio box that was constructed in 2018, or a beagle-board, or whatever comes next

On Wed, 1 Aug 2018 09:55:45 +0200, Joakim Hernberg wrote:

I'd even be willing to invest some time in editing a wiki article or two, in fact I've considered doing so, but didn't want to just start deleting what I consider bad advice :)

Hi Joakim, 'Professional audio' is on my watchlist, so we could discuss something you want to delete at https://wiki.archlinux.org/index.php/Talk:Professional_audio . I still can't spend much time in editing the Wiki, but I'm willing to add my two cents to discussions, you just need to say what I should add to my watchlist. Regards, Ralf

On Wed, 1 Aug 2018 11:48:09 +0200, Joakim Hernberg wrote:

How about we discuss specific options one by one on this mailing list

Hi, a starting point: I assume that zgrep CONFIG_SND_SEQ_HRTIMER_DEFAULT /proc/config.gz usually returns CONFIG_SND_SEQ_HRTIMER_DEFAULT=y nowadays, so there should be no need to mention this by the Wiki. let alone to care about other timer related things, such as HZ or tickless. IMO it's useful to inform that CPU frequency scaling could have impact on real-time audio. To see if a computer is set to 'performance' the user could run cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor Changing the governor to performance could be done by running echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor we don't need to mention all available tools to manage the governor. The Wiki should inform about the audio and realtime group and perhaps about appropriate settings or just link to the appropriate package/s. The Wiki should point out that rtirq is useful and perhaps explain how to set up RTIRQ_NAME_LIST of /etc/rtirq.conf. I don't know if the Wiki should provide a pointer to 'options snd slots=' by /etc/modprobe.d/alsa-base.conf or aplay -l and similar commands or even explain jack settings. For my machine BIOS settings seem to be irrelevant, but for some Intel machines there seems to be at least one important option. It should be pointed out that linux-rt could be useful, but it's not necessarily a must-have. Information on how to set up linux-rt is not needed, the user could get one from AUR. Informing about 'threadirqs' is important. I don't know if page table isolation matters at all and have no time to test it. Perhaps a 'GRUB2' example doesn't belong to the 'Professional audio' Wiki. [rocketmouse@archlinux ~]$ grep threadirqs /boot/syslinux/syslinux.cfg MENU LABEL Arch Linux ^threadirqs APPEND root=LABEL=archlinux ro threadirqs MENU LABEL Arch Linux threadirqs ^nopti APPEND root=LABEL=archlinux ro threadirqs nopti How to set up syslinux or any other bootloader's config also doesn't belong to the 'Professional audio' Wiki. Pulseaudio and flashwhatsoever for some users might be useful for their pro-audio environments. For me gr-55_floorboard and nano_basket are useful and both Linux apps are much more related to a pro-audio environment, than pulseaudio and flashwhatsoever are. Neither integration of pulseaudio, nor informing about applications such e.g. gr-55_floorboard belongs to this Wiki page. I stop here for the moment, since this mail already is quite long. Regards, Ralf