The Audio Configuration Checklist

Optimize your system for ultimate performance.

Moderators: khz, MattKingUSA

User avatar
CrocoDuck
Established Member
Posts: 1042
Joined: Sat May 05, 2012 6:12 pm
Contact:

The Audio Configuration Checklist

Postby CrocoDuck » Tue Feb 23, 2016 9:32 pm

Hi there!

As you know guys many of the pages we are used to refer to when configuring the system are kinda getting old. As such, I would like to make a list of the most fundamental audio tweaks and hear from you if you think they are "up to date".

  • During installation, avoid to format partitions to Btrfs and use instead something like ext4 so that linux-rt is properly supported (the note on the Arch Linux Wiki refers to 3.14.12_rt9. Is this still the case?).
  • Use the noatime mount option for the filesystems through /etc/fstab.
  • Set low swappiness (<= 10) and 50 as cache pressure through /etc/sysctl.d/99-sysctl.conf.
  • Use the noop kernel IO scheduler. This action makes sense by reading this and it is a good idea with SSD drives (see below). Moreover, this package implements this tweak. However, it would be nice to know more. Any of you with a detailed explanation of why noop helps?
  • Perform specific SSD optimization if it is the case.
  • Install jack and pam. Edit /etc/security/limits.d/99-audio.conf and /usr/lib/udev/rules.d/40-hpet-permissions.rules.
  • Set interrupts frequencies for hardware timers through /etc/sysctl.d/60-max-user-freq.conf and/or a Systemd service executing a startup script (obsolete?).
  • Install rtirq and boot with threadirqs using /etc/default/grub.
  • Tweak a standard kernel using cgroups (effective?) or install/build a lowlatency or realtime kernel.
  • If you are on a laptop an want powersave features, tlp seems ok with audio (this is just my experience).

This is written with Arch Linux in mind and detailed description of the steps can be found here. I confess it would be nice to have a package implementing these tweaks just after a fresh installation... I guess I could write a PKGBUILD... but only after your feedback :D !
Last edited by CrocoDuck on Sun Feb 28, 2016 7:59 pm, edited 1 time in total.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

gimmeapill
Established Member
Posts: 545
Joined: Thu Mar 12, 2015 8:41 am

Re: The Audio Configuration Checklist

Postby gimmeapill » Wed Feb 24, 2016 8:37 pm

Nice initiative ;-)

Some comments:
[*] During installation, avoid to format partitions to Btrfs and use instead something like ext4 so that linux-rt is properly supported (the note on the Arch Linux Wiki refers to 3.14.12_rt9. Is this still the case?).

4.1.15_rt17-1 is the latest working fine as of writing, 4.4 doesn't seem ready for mass consumption.
btrfs wouldn't be my first choice either.
ext4 is the easiest, safest bet.
In case of SSD, I would maybe try with a new flash optimized file system like F2FS - you can even use it for the root filesystem in arch (ok, I didn't have the balls to try it - just saying).
[*] Use the noop kernel IO scheduler. This action makes sense by reading this and it is a good idea with SSD drives (see below). Moreover, this package implements this tweak. However, it would be nice to know more. Any of you with a detailed explanation of why noop helps?

Confirmation: noop doesn't bring any benefit for an HDD (I just tried it again), that's only for SSDs.
And the Parabola guys got it wrong anyway. Just reading parabola-proaudio-settings.sh:

Code: Select all

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

That last line relies on the assumption that there a single drive on your system which also happens to be an SSD - red flag!
There is a much smarter way to do this:

Code: Select all

/etc/udev/rules.d/60-schedulers.rules

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

Source: https://wiki.archlinux.org/index.php/Maximizing_performance#Mount_options

I think we could add one simple point: SSD highly recommended.
I have a mixed config with M2/SSD (root) + HDD (/home), and Ijust discovered that the jbd2 driver for the HDD was killing performance at regular intervals (See http://forum.renoise.com/index.php/topic/46412-low-latency-and-xrun-optimizations-on-linux/page-2)
Which bring next the question: what would be the optimal settings for rotating disks, appart from ext4 + noatime?

As for the prebuilt optimization package, I don't particularly like the idea to make assumptions and apply optimizations blindly - too many configuration variants. It should at least test the configuration (memory, hdds, cpu) and ask a few questions like: "pick up your favorite sound card from the list below", "are you even using midi?" or things like that...

gimmeapill
Established Member
Posts: 545
Joined: Thu Mar 12, 2015 8:41 am

Re: The Audio Configuration Checklist

Postby gimmeapill » Wed Feb 24, 2016 8:44 pm

Adding this one:
https://www.linuxmusicians.com/viewtopic.php?f=27&t=15042
I was not convinced enough to keep it activated, but for some configs it might make sense...

User avatar
CrocoDuck
Established Member
Posts: 1042
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: The Audio Configuration Checklist

Postby CrocoDuck » Wed Feb 24, 2016 9:04 pm

gimmeapill wrote:
As for the prebuilt optimization package, I don't particularly like the idea to make assumptions and apply optimizations blindly - too many configuration variants. It should at least test the configuration (memory, hdds, cpu) and ask a few questions like: "pick up your favorite sound card from the list below", "are you even using midi?" or things like that...


I was thinking the package would just cover the very basics, so that the user can concentrate on the tricky part and not on the staples. I think its main action will be install jack, pam and rtirq (and few other stuff) and put sensible default configuration in place. For the most serious part, where editing important conf files, I was thinking, as you suggest, of a semi-auto mode, like:

Code: Select all

noatime is a suggested mount parameter. Do you wanna edit /etc/fstab now? (Y/n)


and if yes it opens /etc/fstab with root privileges (uhm... will I need sudo?..) and the default system editor for the user to make the change. This sort of thing... Not sure how good of an idea is though... like... I will make it to take the required backup files but... it feels dangerous. Do you have better suggestions on this point?

P.S. I could also add links to the documentation realtimeconfigquickscan style... or make a sort of fork of realtimeconfigquickscan that allows the user to make changes as above.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

gimmeapill
Established Member
Posts: 545
Joined: Thu Mar 12, 2015 8:41 am

Re: The Audio Configuration Checklist

Postby gimmeapill » Fri Feb 26, 2016 11:23 am

I wouldn't recommend the automated configuration change part - that doesn't fit well within the Arch philosophy and would probably be a royal pain to maintain in the long run (not to mention the risk to break things and be blamed loudly for it).
I'm convinced this kind of auto stuff would probably be more appreciated by the *buntu crowd or other release based distros where users expect plug & play for everything - and don't want to know the details (nothing wrong with that by the way).
But if you feel up to the task, why not. You should also check the work by those guys then: https://aur.archlinux.org/packages/rtapp/ (disclaimer: I don't trust them anymore than Parabola folks).

Looking at the posts here, It think we often miss the point. We jump to conclusions and end up recommending RT and midi tuning to beginners who don't even have outboard gear, or any low latency requirements. Not to mention that the tweaks are often a shot in the dark.

Why not start by the beginning and define tuning scenarios by gathering user's requirements (by asking questions if necessary - as mentioned in the audio wiki). This should help narrow down the configuration options - as well as setting the users expectations right.

Here are some user profiles that come to mind:

01 - Listen to music on my computer = mainstream user -> you don't need any performance tuning, go away (by away, I mean to the support forums for your distro, not meant in an negative way).
02 - Gamer -> you don't need any audio performance tuning, go away (by away, I mean to the support forums for your distro, not meant in an negative way).
03 - Audiophile -> get rid of pulse audio, get a decent DAC, high bit depth & sample rate - priority is not to have a single xrun, low latency is not a requirement, although setting up an RT config may help achieve this (as these guys seem to think: http://www.audio-linux.com/).
04 - Podcaster -> same as 01 with audio in working? Same as mainstream user?
05 - Video/film producer -> low latency? no idea what would be the specific requirements there.
06 - DJ -> Needs 2 stereo outs, possibly several DACs aggregated as one. Use Mixxx?
07 - DJ with control vinyls -> 06+ add a pair of stereo inputs + low latency (~10ms should still be good).
08 - Musician/Producer who uses soft synths and sequencers only: no need for audio capture, latency in the 20ms-30 ms ballpark should be ok
09 - Musician/Producer who plays with soft synths and sequencers but has also external gear -> 08 + midi timing tweaks, audio in. Low latency needed (<20ms?)
10 - Musician/Producer who records an external instrument, no real time processing -> Low latency not necessarily needed (need then direct monitoring on the audio interface)
11 - Musician/Producer who records an instrument, uses the computer as an effect processing unit in real time -> add midi timing tweaks, possibly audio in. Lowest latency critical.
12 - Runs audio windows programs in wine? -> wineasio, wine-rt & co.
13 - non x86 cpu? embedded device?

Already 13 - no need for that many tuning profiles, but you get the idea...
Anyway, once the user requirements are roughly defined, there's a higher chance to get things right in the tuning section - be it by a documentation checklist of a semi automated suite of menus that tweak conf files.

Now the things I think we lack in the tuning checklist:
- Up to date documentation on the existing tweaks - sometimes even a human readable explanations on what they do (The wiki.linuxaudio.org is the best in class here, would just need a few updates).
- Each tweak should also have a kind of timestamp, if possible, like "tested with this kernel/jackd/whatever version, works as of xx/xx/201x"
As we've seen, the Linux ecosystem is a fast moving target, so this thing needs to be designed with updates/obsolescence in mind.
- Proper measurement tool(s).
This brings us back to the "shot in the dark" part. As I read somewhere: if you want to optimize something, you should start by measuring it.
Unfortunately, it doesn't look like there is any single user friendly tool that would tell you what kind of latency your system is capable of, and where are the bottlenecks. According to the user scenarios, it would maybe be possible to run an appropriate benchmark before / after tuning, something like "cyclictest -p95 -t" with hackbench running or maybe simply starting jack with various settings and measuring xruns at various settings.
Btw, I suggested such a feature https://github.com/raboof/realtimeconfigquickscan/issues/5
This goes back to your measurement idea.

Overall, I think the realtimeconfigquickscan is the right approach (thx again Raboof for getting many of us started), it would just benefit from a few updates/extensions...
Last edited by gimmeapill on Fri Feb 26, 2016 2:09 pm, edited 1 time in total.

User avatar
raboof
Established Member
Posts: 1625
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Contact:

Re: The Audio Configuration Checklist

Postby raboof » Fri Feb 26, 2016 2:05 pm

CrocoDuck wrote:I could also add links to the documentation realtimeconfigquickscan style... or make a sort of fork of realtimeconfigquickscan that allows the user to make changes as above.

I think that'd be a cool feature to add.

User avatar
raboof
Established Member
Posts: 1625
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Contact:

Re: The Audio Configuration Checklist

Postby raboof » Fri Feb 26, 2016 2:06 pm

gimmeapill wrote:Overall, I think the realtimeconfigquickscan is the right approach (thx again Raboof for getting many of us started), it would just benefit from a few updates/extensions...

Yeah, sorry about being a bit quiet on that front... help certainly welcome!

User avatar
CrocoDuck
Established Member
Posts: 1042
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: The Audio Configuration Checklist

Postby CrocoDuck » Fri Feb 26, 2016 8:24 pm

Thanks guys. Really appreciated. I confess that, indeed, I am scared by messing automatically (or semi-automatically) with conf files. gimmeapill, your point about measurements are pretty right. I am starting coding my "measurement suite" in Julia. Julia performs very well and can be run, if Julia is installed, the same way a shell script is run. This Julia package already supplies ALSA and JACK compatibility. I have already been streaming audio with no hassle. When we think about an Audio workstation we think of a system that can perform very differently depending on how a big number of variables are set. This is starting sounding like an optimization problem in the real mathematical sense... that could be solved with this packages. It would be probably very interesting to give to this idea a go... I guess...

Back to the "auto configuration" thing: I think I will go on trying to implement it. The first thing I had in mind was to make a tool for me that helps in the routine "optimization" I go through every time I install Linux (I do pretty much the same things over and over, so makes sense to automatize them). If I am able to make it robust I will publish it. I guess that a good idea is to try to mess with confs as little as possible and implement things as services that run at boot time.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

gimmeapill
Established Member
Posts: 545
Joined: Thu Mar 12, 2015 8:41 am

Re: The Audio Configuration Checklist

Postby gimmeapill » Fri Feb 26, 2016 10:14 pm

A fresh approach to an old problem - I like it, go on ;-)

User avatar
CrocoDuck
Established Member
Posts: 1042
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: The Audio Configuration Checklist

Postby CrocoDuck » Sat Feb 27, 2016 5:04 pm

Ok cool people, here what I think it could be a better idea: do the Arch way. The PKGBUILD will just install the very basic package dependencies for a workstation (jack, pam and rtirq). tlp, linux-rt, cpupower and similar will be listed as optional. The configuration files placed by the package themselves will be not edited, nor automatically or semi automatically. I think I will bring back realtimeconfigquickscan to the AUR first, so that I can include it as a dependency. I will also include a systemd service for the RTC frequency stuff and maybe few other services if I see fit. This way the package would be a configuration helper: gives you the very fundamentals, shows to you what else you can get and makes you able to benchmark your system and configure it your way. It would make life not much easier at the end of the day, as it makes our life different by just a pacman issue. However, I guess it could be helpful for novices, as a tutorial now can be written as "install this and edit these". Maybe I will add a simple script that reads the output of quickscan and redirects the "not good" fields to the relative Arch wiki pages. Does it makes any kind of sense?

gimmeapill wrote:A fresh approach to an old problem - I like it, go on ;-)


I will start code my way in this direction as well. I think it might not be very practical: solving optimization problems can be time demanding, especially in this case where repeated measurements have to be done. It could be a very interesting experiment though and maybe shed some light. I have few scripts ready from my Master project that allow to plot histograms of latency values and I can write one that works out the xruns frequency or some kind of xruns stats... I can probably share them and/or include them in the projects above.
Last edited by CrocoDuck on Tue Mar 15, 2016 9:24 pm, edited 2 times in total.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

User avatar
raboof
Established Member
Posts: 1625
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Contact:

Re: The Audio Configuration Checklist

Postby raboof » Sat Feb 27, 2016 9:51 pm

CrocoDuck wrote:Maybe I will add a simple script that reads the output of quickscan and redirects the "not good" fields to the relative Arch wiki pages.

I'd be happy to include them in the realtimeconfigquickscan output itself, just send a PR at https://github.com/raboof/realtimeconfigquickscan :)

User avatar
CrocoDuck
Established Member
Posts: 1042
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: The Audio Configuration Checklist

Postby CrocoDuck » Sat Feb 27, 2016 10:46 pm

raboof wrote:
CrocoDuck wrote:Maybe I will add a simple script that reads the output of quickscan and redirects the "not good" fields to the relative Arch wiki pages.

I'd be happy to include them in the realtimeconfigquickscan output itself, just send a PR at https://github.com/raboof/realtimeconfigquickscan :)


Brilliantly cool! I will do that very soon.
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

User avatar
CrocoDuck
Established Member
Posts: 1042
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: The Audio Configuration Checklist

Postby CrocoDuck » Tue Mar 15, 2016 9:24 pm

Hi there!

Sorry it has been a while. Here the package prototype:

PKGBUILD:

Code: Select all

# Maintainer: CrocoDuck <crocoduck dot oducks at gmail dot com>

pkgname=proaudio-conf-helper
pkgver=0.1
pkgrel=1
pkgdesc="Pro Audio Configuration essential dependencies and services"
arch=('i686' 'x86_64')
license=('GPL')
depends=('jack' 'pam' 'rtirq' realtimeconfigquickscan-git)
makedepends=()
checkdepends=()
optdepends=('tlp: Linux Advanced Power Management'
            'linux-rt: The Linux-rt kernel and modules'
            'linux-rt-bfq: Linux Kernel and modules with the RT patch and the BFQ scheduler.'
            'linux-rt-lts: The Linux-rt-lts kernel and modules'
            'libflashsupport-jack: JACK-audio-connection-kit support for Flash'
            'cpupower: Linux kernel tool to examine and tune power saving related features of your processor')
provides=("${pkgname}")
conflicts=("${pkgname}")
install=proaudio-conf-helper.install
source=("proaudio-helper-set-RTC-freq.service" "proaudio-helper-set-RTC-freq.sh")
md5sums=('402f5bbbad3dccaea01c9f49dfbbe48f' '2a19a389f020c428ed5f99143cf4a63e')

package() {
   install -D proaudio-helper-set-RTC-freq.service "$pkgdir/etc/systemd/system/proaudio-helper-set-RTC-freq.service"
   install -D proaudio-helper-set-RTC-freq.sh "$pkgdir/usr/bin/proaudio-helper-set-RTCfreq.sh"
}


proaudio-conf-helper.install

Code: Select all

post_install() {
  echo -e "\nRTC interrupt frequency tweaking at boot is supplied by proaudio-helper-set-RTC-freq.service.\nEnable at boot: 'sudo systemctl enable proaudio-helper-set-RTC-freq.service' in a terminal.\nRun 'realTimeConfigQuickScan' or 'QuickScan' in a terminal to check your system configuration\n"
}

post_upgrade() {
  post_install
}


proaudio-helper-set-RTC-freq.service

Code: Select all

[Unit]
Description=Set the highest requested RTC interrupt frequency

[Service]
ExecStart=/usr/bin/proaudio-helper-set-RTCfreq.sh

[Install]
WantedBy=multi-user.target


proaudio-helper-set-RTCfreq.sh

Code: Select all

#!/bin/bash

# Set the highest requested RTC interrupt frequency
# Permissions: 755
echo 3072 > /sys/class/rtc/rtc0/max_user_freq
echo 3072 > /proc/sys/dev/hpet/max-user-freq


As you can see, it is just a simple metapackage that smuggles in a startup service for the timers. How do you like it? Do you think there would be cons in having these packages supplied by a meta? Do you think it is pretty much useless? (well, at least I practiced PKGBUILD's stuff...)

I was thinking to write bash scripts that try to guess good defaults for the configurations files. However, instead of installing them in place, it will install them as examples somewhere, with a comment screaming "USE AT YOUR OWN RISK".

raboof wrote:
CrocoDuck wrote:Maybe I will add a simple script that reads the output of quickscan and redirects the "not good" fields to the relative Arch wiki pages.

I'd be happy to include them in the realtimeconfigquickscan output itself, just send a PR at https://github.com/raboof/realtimeconfigquickscan :)


I am on my way to figure out how to send a PR... it will arrive... hopefully...
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?

gimmeapill
Established Member
Posts: 545
Joined: Thu Mar 12, 2015 8:41 am

Re: The Audio Configuration Checklist

Postby gimmeapill » Wed Mar 16, 2016 10:30 am

A first sight the package itself looks fine, and it is laudable that you are spending time to try to improve things, but I still don't like the approach:
- Personal preference: no additional systemd service of any kind on my system, or at least I would leave that to official packages.
I'd rather put that in my jack startup. But yeah, fair enough, it's the easiest way to do it for the user...
- That particular tweak is for midi timing only, and the usefulness on a modern system is doubtful:
http://wiki.linuxaudio.org/wiki/system_configuration#timers

I understand this is more of a test, but creating a systemd service to apply a fix for something that may or may not be an actual problem is not tackling issues in the right order.
Logically, the first step should be to measure midi jitter on a modern standard system (if that even exists), to see if there's a real midi timing problem, then apply tuning, then measure again.
once done, if that tweak happens to be still relevant, update the wiki (with the kernel version it was tested with), the rtquickscan, and then, maybe create a package to automate the tweak (or give users some hints on how to do it). Right now I just see another shot in the dark.

Now, trying to be a bit more constructive: there might be a way to measure alsa and/or jack midi latency without external hardware in a reproducible way. I'm thinking about creating virtual midi ports with snd-seq-dummy, sending data back and forth and measuring the time it takes - the way Jack io delay works but with midi. Just an idea...I'm not able to help with the implementation unfortunately...

User avatar
CrocoDuck
Established Member
Posts: 1042
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: The Audio Configuration Checklist

Postby CrocoDuck » Fri Mar 18, 2016 8:24 pm

Cool! Thanks for the feedback! I confess I felt dirty when I realized I was indeed smuggling a systemd service inside a system... Anyway, I think I will keep the package for myself at the moment. I am using the service and I prefer to have a package taking care of it instead of having wild files which I forget about. It will help me setting up my systems when I make fresh installs.

Yes, it totally makes sense to try to shed some light on what can improve performances for real at the current system software versions first. Your idea make sense... but I am rubbish with real programming languages and have no idea where to start... but I will look around. I have the feeling that writing/reading MIDI messages is not too complicated (which usually means it is a ring of Hell).

By the way, I have started playing with Perl and realtimeconfigquicksan, which I forked. As soon as I get something that is not rubbish and it is actually useful I will submit a PR. I guess that contributing to existing software is the best way to start as a "developer" (with quotes, as I guess I will never be proficient enough...). realtimeconfigquickscan appears ideal, as it is a script, it has few dependencies, does not need to be built and makes you learn about the system. I am very slow a learning tho, so my "very soon" has just become a "at some point".
Check my Linux audio experiments on my SoundCloud.
Browse my AUR packages.
Fancying a swim in the pond?


Return to “System Tuning and Configuration”

Who is online

Users browsing this forum: No registered users and 1 guest