JackWinter mentioned several times in various threads that the reatimeconfig script is outdated and many points are not necessary. Mabye it needs a major rehaul?
lilith wrote:JackWinter mentioned several times in various threads that the reatimeconfig script is outdated and many points are not necessary. Mabye it needs a major rehaul?
Oh, just new "git clone" and tested, now it works. Great, I had not noticed that.
Thank you!
lilith wrote:JackWinter mentioned several times in various threads that the reatimeconfig script is outdated and many points are not necessary. Mabye it needs a major rehaul?
That's why I opened this thread, among other things.
Instead of just saying what is wrong or outdated it would be more constructive to list it here. Ideally with a correct or current correction suggestion.
==> max_user_watches
The "increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288'" I find confusing. For a newcomer, perhaps even more confusing.
There are references on the net on adjusting the fs.inotify.max_user_watches value also for enhanced performance. But it remains very unclear where these references come from and if adjusting this value actually does anything at all. The max_user_watches parameter sets the maximum number of files your system can monitor with inotify (which is part of the kernel) for changes. Setting this parameter too low results in inotify failing. Setting it too high can make inotify needlessly consume memory. Best is to not touch the default settings as setting this parameter is unrelated to performance in an audio context.
==> max_user_watches
The "increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288'" I find confusing. For a newcomer, perhaps even more confusing.
There are references on the net on adjusting the fs.inotify.max_user_watches value also for enhanced performance. But it remains very unclear where these references come from and if adjusting this value actually does anything at all. The max_user_watches parameter sets the maximum number of files your system can monitor with inotify (which is part of the kernel) for changes. Setting this parameter too low results in inotify failing. Setting it too high can make inotify needlessly consume memory. Best is to not touch the default settings as setting this parameter is unrelated to performance in an audio context.
Ah, okay, I missed that too. Whereby I find the basic idea of at that time "tmpfs" later then "shm" in the RAM great to move out since the audio in the RAM is worked off faster and the hard disk spares. I would take that into the realTimeConfigQuickScan.
khz wrote:Whereby I find the basic idea of at that time "tmpfs" later then "shm" in the RAM great to move out since the audio in the RAM is worked off faster and the hard disk spares. I would take that into the realTimeConfigQuickScan.
I'm not sure I understand what you mean, but all means PR a proposal
khz wrote:"Shm" - back then "tmps" - outsources the jack audio processes to RAM.
The RAM is faster than writing to the hard disk and the hard disk is spared.
Yes, it would be great to check that there is indeed a tmpfs mounted on /dev/shm, which JACK would use. PR welcome!
lowlatency.linuxaudio.org Linux Audio Low-Latency Performance How-To
points to a very outdated wiki page. Can this be removed? I think a single link to the wiki (already present) is sufficient IMHO.
Also, the quicktools link points to an odd, outdated site. Is this link necessary?