The Audio Configuration Checklist

[gimmeapill]

Croco, check this:

http://www.grame.fr/ressources/publications/Timing.pdf

Jack 2 has a profiling mode that seems to provide most of what we need.
Didn't have a chance to test it yet (just got the tip from jhernberg https://aur.archlinux.org/pkgbase/linux-rt/#news)
But we may not have to reinvent the wheel, which is rather good news

[CrocoDuck]

Croco, check this:

http://www.grame.fr/ressources/publications/Timing.pdf

Jack 2 has a profiling mode that seems to provide most of what we need.
Didn't have a chance to test it yet (just got the tip from jhernberg https://aur.archlinux.org/pkgbase/linux-rt/#news)
But we may not have to reinvent the wheel, which is rather good news

SLURP!

[Xzu Rukneg]

"The Audio Configuration Checklist"?
I think it's the job of audio-distro developer’s.

many of the pages we are used to refer to when configuring the system are kinda getting old.

I agree.

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 !

The "kxstudio-default-settings" don't do that?

Missing in your list: check bios-motherboard feature about cpu governance: like "cool'n quiet" option for amd.

[GuntherT]

I think the Audio Configuration Checklist is useful for those who want to tweak a standard distribution or just want to learn about this subject. I disagree that it is the "job" of audio-distro developers. I am not aware of any audio-distro developer who gets paid to do this, unless you are referring to donations, which if I had to guess probably add up to less than $100 a year for someone like GMaq.

Open source software is typically a volunteer, community effort, and the sharing of resources and information is vital to its overall health and survival. I think collaborating to update the checklist has value. Spinning another audio distro? ...not so much, but up-to-date documentation is something many in this community agree is needed.

The thread is focused on Arch, so "kxstudio-default-settings" does not really apply since it is a Debian package.

I think your point about checking BIOS settings is good, and there are probably other settings for Intel systems that could be added as well.

[CrocoDuck]

I think your point about checking BIOS settings is good, and there are probably other settings for Intel systems that could be added as well.

Agreed. It would be nice to know if any of you guys use any particular BIOS tweak. Personally I let the kernel handle the CPU's through the ondemand governor (I prefer this way, it has been a few years since I stopped noticing any difference on my machines by pushing the cores), but there are probably many little life savers in there. Maybe I will spawn a new thread.

Unfortunately I had little to no time to devise tests to see how effective are the adjustments described in the wiki, or whether some new adjustment should be invented... Many things I wanted to try, buy I have only been able to accomplish a few...

[Xzu Rukneg]

Open source software is typically a volunteer, community effort, and the sharing of resources and information is vital to its overall health and survival. I think collaborating to update the checklist has value. Spinning another audio distro? ...not so much, but up-to-date documentation is something many in this community agree is needed.

I agree.

What I want to say is just a testify. I think today musician can just use audio-distro as kxstudio and don't worry about anything, particularly "GNU system" and linux kernel.
Install package by package manager is the most we can ask to do for a common user.
But it's just my opinion.
There also people like me who can try to help to reach that goal but without real qualification (all learned "on the job" by issue, like the bios thing).

So, for now, what's the plan about up-to-date documentation? (And where?)

EDIt: about bios: I don't think there is other thing to check than the cpu governance. (except of course crazy setting and over-clocking etc..) Also, that depend of course of the use (x16 rt recording or x2 stereo output?).

[CrocoDuck]

This is the wiki we refer to, especially this page.

[Xzu Rukneg]

Code: Select all

Recent posts on the “Linux Audio User” mailing list

=>404 not found

Code: Select all

Recent posts on the “Linux Audio Announcement” mailing list

=>404 not found

Good luck!
Sorry too funny..

[GuntherT]

What I want to say is just a testify. I think today musician can just use audio-distro as kxstudio and don't worry about anything, particularly "GNU system" and linux kernel.
Install package by package manager is the most we can ask to do for a common user.
But it's just my opinion.

EDIt: about bios: I don't think there is other thing to check than the cpu governance. (except of course crazy setting and over-clocking etc..) Also, that depend of course of the use (x16 rt recording or x2 stereo output?).

I'm with you there. Adding KXStudio stop a Debian or Ubuntu installation or using AVLinux (pre-configured Debian + KXStudio) is the best option for a typical musician, in my opinion.

I'm not really sure what other BIOS settings may be pertinent to check, but I've read that turning off hyper-threading or disabling USB 3.0 has been useful for some. For others, it may make no difference. I have no first-hand experience related to this, but your comment reminded me of other threads I've come across, so I thought it was something to consider.

[CrocoDuck]

I'm not really sure what other BIOS settings may be pertinent to check.

I think it would be nice to have some kind of "bullet points" of things to check in the BIOS when things don't work the way one wants, like hardware options that might enabled/disabled in order to achieve a certain behaviour, IRQ things, etc...

For example, there were a number of threads that were like "check in your BIOS whether IEEE 1394 is enabled", stuff like that.

[thetotalchaos]

echo noop > /sys/block/sda/queue/scheduler[/code]
That last line relies on the assumption that there a single drive on your system which also happens to be an SSD - red flag!

Actually it assumes that the SSD is the main drive. Pretty reasonable assumption i suppose.
But if someone thinks that 'noop' parameter can be harmful in case there is NO SSD, then i can conceder editing/removing the line, because at the end this line is not directly related to pro audio tuning. Its a bonus for the SSD user to receive a proper settings ootb

best regards Totalchaos

[gimmeapill]

There is a clean way to activate the right scheduler for the right drive using a udev rule.
It is explained in the Arch Wiki (surprise):
https://wiki.archlinux.org/index.php/Im ... nvironment

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"

Actually it assumes that the SSD is the main drive. Pretty reasonable assumption i suppose.

Actually...no. & I have a first hand example. My Toshiba notebook from 2012 comes with a mixed SSD/HDD config, but it is a cheap version where the small M2 SDD is used as a cache drive for the stock Windows installation. Once moved to Linux, that M2 SSD is detected as /dev/sdb and the spinning SATA HDD as /dev/sda (changing the boot order in the BIOS wouldn't have any effect here). Needless to mention, I'm using the SDD as my root filesystem (first drive is /dev/sdb) and the HDD for data (/dev/sda). So the "assumption" would be wrong here. And yes, setting noop on an HDD does degrade performance in a noticeable way, but improves it on an SSD - so this is a useful tweak for minimizing latency.

Again, blindly relying on assumptions is the wrong approach if you are creating services and want to deploy things for many users with heterogeneous configs (that's the former sysadmin and software packager speaking here). Whenever possible, the existing HW/SW config should be tested before applying tweaks.

[CrocoDuck]

Again, blindly relying on assumptions is the wrong approach if you are creating services and want to deploy things for many users with heterogeneous configs (that's the former sysadmin and software packager speaking here). Whenever possible, the existing HW/SW config should be tested before applying tweaks.

+1 for me. Services and scripts allow a great deal of automation, so it makes sense to make targeted optimizations through them without relying on assumptions about user configuration, which will produce good setup for few and not optimal setups for most. The udev rule appears a way better choice to me, as it allows, indeed, targeted adjustments independently of the particular system. Of course, we should test it first. Again, I wish I had a test computer...

[gimmeapill]

Of course, we should test it first

This one is pretty safe (just don't overwrite the rule if it already exists, mkay?)

Code: Select all

[gimmeapill@pill-mobile4 ~]$ cat /sys/block/sda/queue/scheduler 
noop deadline [cfq] 
[gimmeapill@pill-mobile4 ~]$ cat /sys/block/sdb/queue/scheduler 
[noop] deadline cfq 

[hucasys]

I'm a musician and I DON'T want to spend all of this time "tweaking" the system, but PLAYING!