I’ve posted on the MixBus forum, but here also since it applies upstream to Ardour.
Perhaps only a MacOS thing (unknown) but really high track counts in Ardour/MixBus fail miserably. I specifically compare to something like PTStudio with a limited track count of 512 which can be up to 7.1.4 wide each. I suspect the team doesn’t test anything like this and maybe does not realise the issue.
h
Make 128 new 16-ch tracks from template across several test Macs. Takes from 1:45 to 5:00+ for the spinning beach ball to stop and tracks to appear. A little more time before the timeline can move. Subsequent playing (of empty tracks) shows on and off 100% red DSP usage. No audio yet, no plugins yet. Activity monitor reveals Macs largely idle.
Subsequent testing brought the time-to-play down somewhat by saving the template with inputs and outputs disconnected and the panner bypassed, but heavy DSP load still shown while activity monitor shows bored Macs.
Having used MB for a while, and Ardour recently (since the v11 licensing fiasco) I’m neither surprised nor complaining, just want to encourage the team to find out how Ardour compares when under loads.
I use, but do not prefer PTStudio, but do rely on it comfortably when I need big sessions. Even a lowly i7 with High Sierra can start a PTStudio session with 512/7.1.2 tracks in just a few seconds with no spinning beach balls. I’m having trouble seeing that success with Ardour/MB.
h
Paul - when @hodger mentioned this on the Mixbus forum I tested it here with Ardour on Windows (128 tracks each with 16 channels). Admittedly the session would take over 30 seconds to load but once loaded the DSP readings weren’t too bad.
And it reminded me… wasn’t there a version of MacOS where apps were being expected to redraw an entire window, just because a small section needed to be updated? I can well imagine how that’d make things less efficient. Or did you & Robin manage to find a fix for it?
We did fix the macOS drawing issue, but there still seem to be drawing issues on some macOS systems with some monitor configurations under some circumstances that we do not yet understand.
I tried an extreme situation like that on my linux workstation, requested to add 256 16-channel tracks, and after being unresponsive for just under 3 minutes Ardour began responding again, but with only 23 tracks added, then became unresponsive again.
While Ardour was unresponsive the right side section of the editor which contains the DSP load display was not redrawn.
After about another 30+ minutes the interface became responsive again, but for less than a minute. During those several seconds the track list still only showed to track 23.
After it stopped responding again none of the window was displayed, just the outer window framem with title bar and a blank gray background.
I was going to leave it running to see if eventually all the tracks would show up, but it crashed after about 45 minutes total running time. When I restarted Ardour it had the session name in the recent session list, but when it opened there were no tracks at all, so it apparently saves the session when first created, but never got to a point where it could save the session with tracks added.
For my tests, all 48kHz with 512 buffer.
I tried again with 128 5-channel tracks and that completed in less than 1 minute.
Admittedly 256 16-channel tracks is extreme and doesn’t seem particularly practical to me, I was just looking for an extreme limit to check the OP contention.
So 128 5-channel tracks seems fine, but I would agree that attempting to add 256 16-channel tracks does “fail miserably” in the sense that Ardour is unresponsive for 45 minutes and then crashes.
I will leave it to others to argue whether there is actually a use case for that many high channel count tracks, but can confirm that at some point there is an ungraceful exit when some resource limit is reached.
I think that somewhat makes sense. Ardour is designed so that the CPU usage is relatively constant for a particular configuration, so playing “empty” tracks will (I think) still be processing buffers with zero’ed out audio samples, and running the gain and pan processors. All of the processing, minimal though it may be, must be completed within the buffer period. With 128 tracks you may have to increase the latency to have time to complete all the processing, especially once you start adding EQ or compressor plugins to the tracks.
Audio/MIDI backend for these tests?
This took a few seconds for me (ALSA backend on Debian, but it’s 8.12, not 9.0).
Just tried 256 12-channel tracks (maximum that showed up for me, couldn’t figure out how Custom worked) and it inserted them all after a good 30 seconds. But it worked! DSP usage spiked for a bit, but seems to be okay in general, though RAM usage is through the roof (it’s using 68% of my 32 GiB of RAM).
Oh, I should add that I used 48kHz as the sample rate and 1024 samples for the buffer size. And, as mentioned earlier, I’m using the ALSA backend. I’m also on Linux (Debian sid/experimental, so Ardour 8.12) with a Ryzen 5900X CPU (so 24 threads) and 32 GiB of RAM.
I had tried using the JACK backend with pipewire-jack.
I will try again with ALSA, but probably not until Monday.
Just tried 16 channels, and 128 inserted in ~30 seconds. I’m scared to go higher mainly because I’m going to run out of RAM! But…it works. DSP stays relatively low (I’m sure it would go up if I had actual audio there, but…yeah).
@hodger It seems like there are a few different things going on here:
In retrospect using the JACK backend was an obvious mistake, because the JACK server has a port limit lower than the channel count, and Ardour exposes all the tracks as JACK ports.
That limit seems like something which should be able to be discovered through the API and the channel creation attempt aborted rather than taking so long to eventually crash. If indeed that is the cause of the crash.
Seems like you can change that (see the -p option). But yeah, I’m curious what happens if you use ALSA.
@hodger - for my Ardour tests (Windows) I’ve been using 48KHz here and 1024 buffer and although (like other testers) the tracks took a long time to get generated, it did work and my DSP reading here was between 25% to 35%. so it’s weird that you can’t make it work with 3 systems. Try increasing your buffer size and let us know if you then see more reasonable DSP figures.
Also - maybe a dumb question - but for 16-channel tracks, what would the 16 channels typically contain?
For a related but inverted test, I have a 1-track session with a 128-ch imported audio file. The track has both input and output disconnected. Ardour reports 4% DSP usage. The Mac Activity Monitor shows Ardour using under 600MB of RAM and the Mac has 98% CPU available.
Sounds ideal. But initiating playback shows the counter start and freeze, same with the meters. Then spinning beach ball eventually leading to a force quit.
The idea is to have material in the session providing context while focusing on particular parts of a bigger project. Think venue setups, museums, motion pictures, episodics or custom installations. Similar to the pursuit of LITE tracks in MixBus, these entities need to get to the monitors with basic level control and a mute, no pans or plugins or chopping of tracks - simple playback.
In smaller chunks, these may be pre-mixes. In larger chunks they may be layers within an architectural project with hundreds of speakers.
Yes I see the same on Windows. 128 x mono tracks gets created okay but Ardour subsequently doesn’t work at all. I can’t even reposition that Playhead, let alone play anything. But if I create 1 track having 128 channels it works fine and likewise, give me about 4% DSP. 
I suspect the “1-track having 128 channels” has no related audio files. I checked and can also create a single empty 128-ch audio track and get a functional timeline and low DSP. However (as before) when I create the 1 new track by importing a 128-ch audio file, the system is non-responsive.