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/realtimeconfi ... n/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...
!
