Which apps use those? It should not be needed anymore, nor should any app use those for audio timing on a modern system (kernel newer than 2.6.39).
This is backwards, prefer a tickless kernel for reliable low latency and low jittter MIDI.
I wrote most of the content on this page in 2006/7 and sadly most of it is out of date and has since been frankensteined by various wiki editors. Take it with a huge grain of salt.
3 Likes
It would be nice if you would be willing to update it, as to date those obsolete information are misleading a lot of people… 
I don’t have the time to update it. Ardour development keeps me busy pretty much 24/7. I also stepped down as linuxaudio.org admin in 2015. It’s time for a new generation to take over that part.
From the time I used Ubuntu Studio and Regular Linux Mint, Ardour would not open at all after been added, it opens.
As you’ve mentioned, this must be outdated, but truth is: It was there and we did all things in the script based on those info.
And indeed, we’ll create an account and check. Many things to discuss, but one thing is for sure: After doing all those modifications, I’ve been recording and mixing a lot with both ardour and MixBus
And here is the GIT HUB link for the .deb
Please take a look and feed back will be wellcome. We’ll probably review everything on Linux.org
We’ll probably be part of it.
Public schools need to be involved. Most public schools in Brazil can’t afford buy software
I’ll definitely recruit people to update de page
We (me and João) will get together tonight and discuss the feedbacks and start looking for the others based on those who run the package
For Ardour/Mixbus, I use a default debian system with less than a handful of modifications:
Installing jackd asks to enable reatime-permissions. I don’t use jack, I only install the package to conveniently setup rt-permissons and groups. After that setting up rtirq-init (and the threadirqs kernel boot option) is sufficient. – The only manual change I made is to re-apply rtirq settings after suspend/resume cycle (similar to https://github.com/jhernberg/udev-rtirq).
That’s all.
On this i7, I don’t even need to change the CPU governor. CPU frequency change are orders or magnitude faster than audio process cycles.
On other systems like ARM or Raspberry Pi, the story is quite different though.
That’ll be great.
The wiki page still mentions kernel 2.6.31 
The complete section https://wiki.linuxaudio.org/wiki/system_configuration#the_kernel as well as https://wiki.linuxaudio.org/wiki/system_configuration#timers can go away.
Back in the day, there was no high-resolution timer, and snd-hrtimer was the shit!
The only two live MIDI apps back then indeed used /dev/rtc (which is why HZ_1000 was useful). These days no app uses that anymore. There are much better option available, and systems perform better with a tickless NO_HZ system that isn’t limited to 1kHz.
It’s still on the https://wiki.linuxaudio.org/wiki/system_configuration#todo list 
1 Like
Could you recommed us any sources where we could read and then optimize making use of these new Kernel’s resources ?
If yes, let us know so we can go ahead and implement them on wherever the info is needed to be updated and on the .deb as well
Hey, here it is!
Wow! It seems to me that I have a lot to learn and things that must be forgotten on this subject. I always thought that most this sources of information was correct. Does the audio distros make this things right?
Hi josander
Well I for one still include all of these in AV Linux, for instance the timer thing, it does no harm to have those settings even if they are not relevant any longer… I include raboof’s realtime config quick scan as a checklist and also as proof to the User that all the important system tweaks have been performed and if I don’t set the hr-timer stuff the scan will fail those 2 items which looks bad and makes the User feel that the system is not fully tuned (even though it actually is)… 
I essentially keep them to avoid well-intentioned but groundless complaints… 
1 Like
Is a tickless timer Robin mentions the default these days on most kernels? Or is some configuration necessary?
I think what you say here makes perfect sense. However, I will experiment with the tickless NO_HZ settings and see if that makes the kernel even better.
We have checked many of the “ready do go” and most of them either do all stuff we wrote in the script or some of it
and yes. We now included support for FireWire Interfaces such as:
Focusrite Pro40
Maudio 2626
Fireface800
Because besides of FFADO and JACkd2 FireWire you need to blacklist the snd_dice chipset in order to use all the adats, buffer sizes larger than 256
Just for info’s sake ok? I know it is beyond the scope of the discussion, but we included support for FireWire interface (many people still use them I do!)
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.