I plan to use ardour as a vst instrument host for live performance. However, DAWs are notorious for freezing up. This is obviously bad if you’re playing live.
With that in mind, on which OS is ardour the most stable?
Thanks!
Ardour itself is almost completely OS agnostic. The only differences are plugin-support and audio-backend (ASIO, CoreAudio, ALSA…) and some a couple of small details.
It’s rather the OS itself (not Ardour), that I’d be worried about.
1 Like
Does it cover OSS on BSD?
We have no OSS audio/MIDI backend.
Would it be a possible consideration in the future to add this backend to the list for BSD users? I don’t use BSD but was curious.
None of the core Ardour developers would have any interest in this. If somebody else wrote a BSD backend, we’d probably merge it if the code quality was good. BSD just isn’t viable as a platform for pro-audio/music creation, and even though Linux is itself a tiny niche inside the very small niche of audio software, BSD is way tinier still. Unless BSD has done a lot of stuff that they previously said they would not do, even basic things like real-time scheduling are not really available on the platform.
Don’t know anything about the audio backends but I thought BSD is the OS which uses OSS I believe like Linux uses ALSA, OSX uses Coreaudio, etc. and from the earlier comment Ardour itself is “almost OS agnostic”. Whether there’s realtime capabilities or not Ardour can still be used to record, edit, and mix.
I do understand it being so tiny in the audio world you’d prefer to not even bother. Was just curious. Thanks for the insight Paul.
@paul As long as the computer I am running Ardour has enough CPU/cores, RAM, and memory to power all the tracks and plugins I am using, I’d assume Ardour would work in live applications just fine as many DAWs do.
I have read in the Ardour manual that this software was made natively on Linux, so in theory wouldn’t it run more stable on Linux OS compared to macOS or Windows? I have Ardour installed on all my computer OS’s, and so far it works great. My biggest concern is having a program crash during a performance.
Not Paul, but I’ve used Ardour on Windows a bit, and a LOT on linux, and I think this has to do with OS configuration and how much you are altering .conf files in Linux and/or how often you’re having registry edits in Windows (the single most destabilizing thing in Windows, imho). After changing my audio production machine to a 7th gen i7 + 32gb RAM + all SSDs, I never once have had Ardour crash unless I was loading a buggy plugin (DrMr, I’m looking at you).
1 Like
@unsafelyhotboots Thank you for the feedback, that makes a lot of sense. I appreciate it! Glad to hear Ardour has not crashed for you. It has happened to me a few times where it has crashed. But I guarantee it is becuase I had Ardour running on a low grade computer and not powerful enough to handle the playback.
Notice in my previous comment I said “After changing my audio production machine” … I routinely got crashes on my old computer that was running 8gb ram on a 3rd gen i5, no graphics cards, HDD. So believe me, I hear you.
Ardour can be pretty lightweight on system resources if:
- you run at the maximum number of periods your soundcard will support (I found the upper ceiling was 4096 for the USB cards I’ve tried).
- avoid sampler plugins that are loading large numbers of samples into the audio engine (DrumGizmo, I’m looking at you).
- avoid built in effects on synths, instead opting to fine tune a sound, then bounce it to audio, then manipulate that to your liking with effects, then bounce that. Rinse and repeat as many times as you need.
1 Like
Thank you for the insight!
I have been using Robin Gareus’s plugins even on Windows/ Mac in Ardour since they seem to use less numbers of sample’s into the audio engine if I need to use effects and they just work. I have been bouncing effects on tracks instead and then importing them into Ardour for editing tracks for things podcasting.
Less numbers of samples than what? The host application gives the plug-in a number of samples to process, and the plug-in processes them. The plug-in can’t choose to (or be designed to) process any fewer than that (though it might in some cases effectively process more)
My bad, I read @unsafelyhotboots last comment wrong. I guess what I was trying to say is my transition to x42 plugins was due to less cpu use from than other plugins I use making it easier to use on my systems which I liked.
Ah - (well maybe x42 does process fewer samples and that’s why they are more CPU efficient… 
)
I could be … Also, I make sure that any startup programs your OS doesn’t need running in the background is a good idea to disable. Even Bluetooth is a good idea to turn off (if you don’t need it), but sometimes I will turn my wifi off too just to use less CPU.
I don’t know how common it is now, but at least in the past there were reports of some WiFi drivers using excessive time scanning for networks and being written in a way that did not allow the kernel real-time scheduling to preempt the WiFi driver when needed.
So not just using less CPU in general, but also improving responsiveness when WiFi was disabled.
As I mentioned that was in the past, perhaps the general cleanup the RT developers have been working on for the last several years has corrected that, but turning off WiFi certainly can’t hurt.
1 Like
@ccaudle Hmmm… that’s good to know. I didn’t realize that helped in the past.
I actually had a similar issue on a Windows 10 PC a while back where the Realtek audio drive went completely out. Even after we reinstalled the driver, nothing would change to get the sound card running again. Maybe it was a cheap sound card or a problem with the OS. Luckily all of our computers run good now.