It’s just a (fairly fast) storage device. It has no particular characteristics other than being much, much faster than a spinning disk and a bit faster than, for example, a USB SSD device. Storing sessions on it with Ardour would be a fine use, but Ardour doesn’t need that.
Thanks Paul . That was the answer I was looking for. All the other explanations where confusing ( at least for me).
Now having said this, It would make sense to install the OS on such a device.
That brings me to the next question : I have plenty of RAM (32 gig). Looking at my " System Activities " Ardour does not use all the memory it requires , as in using shared memory as well. It would make sense to load permanently Ardour, Jack , ALSA into RAM. Shouldn’t that reduce the risk of xruns ? If yes , how would one do that for selected applications ?
M.2 is just a form factor for small SSD devices (and others, you could put a WiFi adapter or cellular modem into an M.2 size module, but on your motherboard is almost certainly for SSD).
For your purposes, you just need to verify which protocols your motherboard supports for the M.2 connectors. For M.2 SSD there are SATA and PCIe pinouts. There is a pin to indicate module type, so the motherboard should be able to detect what type is installed and change configuration automatically if both SATA and PCIe are supported.
That is a common configuration, boot from M.2 then have 2.5" or 3.5" traditional form factor device(s) for additional data storage.
That is an odd assertion. How do you know that Ardour does not use exactly what it requires, no more and no less?
As long as you have your user account permissions set corretly, Ardour will lock the memory required for realtime operation into RAM so that it cannot be swapped out.
You can view the amount of memory your account is allowed to lock with the command ulimit -l. I have seen a lot of configuration instructions that just say set it to unlimited, but I set it to a smaller amount. I want to be notified if some app tries to start locking a ridiculous amount of memory, because that probably indicates an error of some kind.
$ ulimit -l
You can see all permissions with ulimit -a to see whether your account is allowed to use realtime scheduling, lock memory, etc.
If you do not have proper permissions, the most convenient way to fix that depends slightly on which distribution you are using. For most there is a package to verify is installed, then make your user part of a particular user group (often named audio, but could be realtime, rt, jackuser, etc.).
Thanks for the detailed response Chris . I will look into "ulimit -l "
I am running openSuse since … hmmm 2005 … no joke ! The system is stable and does everything I want it to do except they don’t have a realtime kernel .
Even if the installations on different machines seamed to be identical in one or two installations I had zero xruns in other installations there were plenty. So what I am planning to do , since I will have all new hardware to install a second OS with realtime kernel .
At this point in time AVLinux seams to be the choice. Any recommendation ? What are you running ?
The SuSE Enterprise distribution seems to have a RT kernel. Can that be installed on OpenSuSE? SLE 15 RT kernel page
I run Fedora, which currently does not have an easily accessible RT kernel available either. In the past the PlanetCCRMA project at Stanford University built an RT patched kernel for Fedora, but that has not been available for the last several releases for some reason.
I sometimes rebuild the standard kernel with PREEMPT configured, which does not require any patches (which I believe Ubuntu provides as a package named kernel-lowlatency). That suits most low latency needs I have, but lately I just run the default kernel because I have not been running anything which requires low latency.
What latency are you trying to achieve? Depending on your workflow increasing the audio interface latency may be the best solution. That is not always practical, e.g. using software synthesizers or software controlled monitoring, but for mixing low latency is not essential, and for recording if you have a way to control monitoring externally (e.g. analog mixer, audio interface with the ability to mix input to output) you may not need low latency.
Well yes there is a RT Kernel add-on available . Mind you the description does not say a lot in this regard at all . So I went to the forum and the answer is , believe it or not, " yes , even if we can not confirm as yet " !!! Anyway I found it and installed it . Let’s see what happens. Further search at the Suse forum : Yes there are successful OS installations on NVME. I should get the NVME stick by the end of the week (hopefully ) . I am still planning dual boot Suse and AV-linux. or more …
It is my understanding that life network connections can cause xruns. How would on isolate the system during recording time ?
any other things one could do to avoid xruns ?
Using NVMe has been really common in servers for the last several years, you should not have any problems (although the device names may be different than what you are accustomed to).
There are several guides to setting up RT priorities. Make sure you read one that is recent, some advice from years past is no longer applicable.
But in short, no, network connections should not cause problems as long as you set the RT priority of your audio interface higher than your network card.
There is a script called rtirq which can help with that. This is the original development location, but a lot of distributions include it, so check to see if it is in the OpenSUSE or SuSE repositories for convenience. rtirq at GitHub
There is a python script which can check several system configuration items to verify if your system seems properly configured for audio use. Make sure to use the latest version, several items which were outdated and should have been changed a few years ago were finally updated. Can also be installed from pip if you use that for Python software packages. rtcqs at Codeberg (based on previous realtime config quick scan)
Just want to give my 2 cents, as openSUSE was mentioned…
I use openSUSE as my daily driver as well. AFAIK it doesn’t have RT kernel builds anymore, but is that really needed these days ? I vaguely remember Robin mentioned this in older threads on this forum (haven’t searched yet). I thought having high resolution timers was more important…
Anyway, openSUSE Tumbleweed comes with PREEMPT config out-of-the-box, and you can use the “GeekOSDaw” repository for all your audio-related software (incl. the rtirq package). Don’t let the name fool you, it’s pretty neat