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.
I cheated I created all the tracks using Lua Commandline Interface, and then opened the session, which took around 10 mins - I was faster than my coffee + shower morning routine…
Seems about the same. I decided to be a little more patient but gave up after 10 minutes - still erratic and unresponsive. DSP showing 4%, using 1G memory and activity monitor indicating 97% idle.
Wow, this has suddenly gotten weirder… this morning I did a full build of Mixbus (from Monday’s code) but this time using MSVC and guess what… I don’t see those huge delays any more!
So I’m starting to wonder if this could be some bizarre problem with Clang?
Though having said that, Clang has been used to build on MacOS for quite a long time now hasn’t it? So why wouldn’t this be present in previous versions??
[Edit…] and if it is some weirdness with Clang, why does it affect Robin’s Windows build???
Could be many things (maybe Clang versions changed, optimization paths changed, etc). @x42 I forget…which compiler do you use to cross-build for Windows?
Woohoo! After days of testing I’ve finally found a solution to this (on Windows at least). To recap - if I create a large session (128 x mono tracks) then save the session, Ardour would hang (for between 8 minutes and 19 minutes) simply by re-opening the session and clicking on any ruler bar. So what’s the big fix…?
Create the large session as described above and then simply record a short audio track. Subsequently - even after closing the session and re-opening - this totally gets rid of the problem. So might it be getting caused by loading a very large session which has no Start and End markers (or where both markers are zero?)
[Edit…] FWIW if I create a large session in its non-working mode but then I drag some wav audio into the Editor timeline (i.e. rather than recording it) that does produce Start and End markers but it doesn’t solve the long hang at startup. So that initial recording is critical somehow but I don’t know why
Thanks to all for looking at this behaviour from multiple angles. I wish this thread made me more hopeful for improvement - both for Ardour and potentially trickling down to MixBus as well.
