I tried another experiment here where I loaded a session having 128 x mono tracks and just left it sitting there to see if it’d eventually start working - which it does - BUT - it took a full 8 minutes here before Ardour became responsive. Weird…
I then tried launching Ardour from a command line but I didn’t see any output during that 8 mins. So my best guess is that after first loading a session, there’s some loop running somewhere which takes a VERY long time to complete
[Edit…] One more thing… in order to make the session load I need to set my buffer size to 4096. At 1024 it crashes while loading (something seems very wrong here…)
[Edit 2…] I ran Windows Task Manager here and during that 8 minutes my CPU usage was 14% with 13.9% being taken up by Ardour. So it looks like there might be a tight loop somewhere that’s waiting for something to happen - but whatever it’s waiting for is taking a great many loops to complete. Hopefully that might help Paul & Robin.
The current record with a spinning hard-disk on Windows is 1020 mono tracks.
On GNU/Linux with ALSA backend (1024/48kHz) I stopped after 1536 mono tracks (using a SSD), it takes some time to create all the ports and toggle all to recording, but after that there are no dropouts.
Creating Ports takes ages. This is mostly because all backends behave like JACK for compatibility and it takes a backend (or jack server) roundtrip (call + callback) for each track’s ports.
It’s definitely looking like a tight loop though… if you can suggest somewhere where I could add a small g_sleep() I’d be happy to test it here and let you know if something gets screwed up.
This part caught my eye.
While it is understandable in these days of audio workstations needing to be an entire studio in an app, there is no expectation here of recording onto these tracks. They are for playback, but obviously there is no such thing in Ardour as a playback-only track, or tracks created for mixing purposes.
A possible bottleneck when using > 1000 tracks tracks is disk-I/O (here with 1.5k tracks at 48kHz, around 280 MB/sec) and chunked, interleaved writing is usually more of an issue than sequential reading of data.
The 128 x 16 ch empty audio tracks worked here yesterday (no idea how long it took though), I could also save the session, and opening it afterwards took little less than 3 minutes.
After that I tried a couple of times to generate 1024 stereo tracks (the equivalent of 128 16-channels) to check the difference, but I only got 999 tracks (I guess it is a limitation of the new-track-dialog). I made 100 duplicates of the last one, and after a long waiting it worked, with well over 1000 x-runs (ALSA 1024/48kHz). Just trying to vertical scrolling was producing tens of x-runs. I could not manage to save the session, it just crashed.
All empty audio tracks. Probably they were automatically connected to the master, I did not check.
It’d be interesting to know what kinda time delay you’re seeing. On my system the tracks (just 128 mono ones) take around 25 secs to create but after that there’s a massive delay of around 8 minutes before Ardour becomes responsive. Is that all due to some ports getting created?
[Edit…] As another experiment I added a printout to PortManager_register_port() and registering the ports for all 128 tracks took about 12 seconds - after which there was still a huge 8 minute gap. Any ideas what could be happening there??
[Edit 2…]In fact AFAICT all the ports get created, registered and reconnected before the Edtior’s timeline gets drawn. And once it’s drawn you can click on most things without seeing the delay (such as the tracks at the LHS - or the menus - or the mini-timeline etc). But woe betide you if you click Play or if you click on any of the timecode rulers
[Edit 3…] In fact for some reason, I can even click Play today, although it doesn’t actually play the timeline - so there’s definitely something weird going on…
Okay, I was able to import it successfully and play it! Quite easily, too…
[edit] The first time I did it, I didn’t copy it into the session and scrubbing caused it to freeze up. The second time, I copied the file into the session and it was totally fine. RAM usage was quite reasonable too.
Again, this feels like some potentially macOS-specific stuff coupled with some potential limits based on hardware in your case. As I mentioned earlier, 128 16-channel tracks took up a good 70% of my RAM, so I didn’t want to press my luck and try to add more. I never had it lock up to the point where I had to kill it (in any of my tests), FWIW.
How much RAM do you have? What is your processor? How much of this is available to Ardour vs other processes (especially with RAM, if you’re already taking up 20% of the total with other programs and basic OS stuff, then Ardour only has up to 80% of your RAM to actually use before everything will die or macOS kills Ardour — realistically, it’s probably more like 60-70% depending on your OOM killer settings).
Confirmed that I can create 128 16-channel tracks in just over 1 minute when using the ALSA backend.
Unfortunately my machine is running pipewire-jack right now, I am not setup to easily try with jackd as well.
Is CoreAudio the only backend used on MacOS? That would be somewhat similar to pipewire, right? Is there a way to let Ardour take exclusive control of the audio hardware on MacOS comparable to the ALSA backend on Linux or using ASIO on Windows?
I’m also really interested in this @hodger. I’m sure it’s not the only factor, but having created that many tracks, it does take a ton of RAM (perhaps something that can be improved, perhaps not, but certainly the current state of affairs).
JACK is available as well, but uses CoreAudio under the hood.
I wish it was that way. CoreAudio is far superior in almost any aspect. Then again Apple is also in control of the hardware.
This is not possible by design on macOS. There is however an API to select clock-source and lock sample-rate (which is one of the main reason why exclusive access matters).
Stats from here, on a Ryzen Threadripper 2950X with 16 cores and 64GB of RAM; using JACK/Pipewire …
debug/ASAN build: 1min 45 sec for 128 12 channel tracks, 18-20% DSP load (play works fine at this time)
optimized/released build: 1min 20 sec for 128 12 channel tracks, 9-11% DSP (play works fine at this time)
No good reason for those 1-2 minute waits, nevertheless. I bet Reaper doesn’t do that …
[ EDIT: I should mentioned that I’m running at 44.1kHz / 1024 sample buffer ]
[ EDIT 2: it also seems that if I switch to a different workspace from Ardour for a while and then come back, the GUI (after loading these tracks) will be hung. ]
This particular test uses an iMac Pro, 10-core Zeon with 32GB Ram, nothing else running. Other variables that seem to apply is whether you import as 1 track per file or 1 track per channel. I’ve also not strayed from my 48k/512 rate/buffer for consistency in tests.
Just to add to the weirdness… this might either be confined to the latest releases or maybe it’s a Windows only thing. I don’t see the huge delay here if I boot into MacOS Mojave (on the same machine) albeit that I only have Mixbus 10 on Mac. But equally, I don’t see the delay with an old version of Mixbus32C running on Windows.
With Ardour 9 or Mixbus 11 I see it predictably on Windows (both my builds and Robin’s) so if anyone else wants to test this, it’s quite simple:-
Open a session with 128 x mono tracks
Once everything’s loaded and looking normal, click your mouse on any of the ruler bars (at the top of the Editor window)
For the latest builds of Ardour and Mixbus here, that will reliably produce a lengthy hang with each DAW totally unresponsive, quite literally for minutes
I also see better results with MB10 and 32Cv9, with v11.2 issues similar to Ardour 9. In this context of a feature request I’m not trying to read too much into it. I currently don’t have my normal array of different OS’s to try either, and my recent upgrades to Sequoia could easily be suspect. But in any case, from MBv5 through today, I have never had the impression that high track counts could be stable.
Just did this with Ardour 9 (since I had the same thought you had and my distro only has 8.12 right now) and it worked perfectly. Same settings as my earlier attempts, but I’m on Linux and don’t have Windows around to test. It could very well be a Windows-related issue.
I wonder if this is JACK/PipeWire specific, since ALSA seems to give much better performance (more like 30 seconds of waiting).
Interesting. When I repeated this with Ardour 9 (128 12-channel tracks), it added them in ~30 seconds, froze for another minute or so, and then it’s functioning normally. Switching away (e.g. to this workspace to type out this reply) and then switching back seems to be fine on my end.
