Increased track count

[x42 (Robin Gareus)]

@John_E

@x42

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.

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?

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…

[hodger]

@chiraag-nataraj

What happens if you use a 1024 sample buffer? I’m also using 48k sample rate, but I tend to use 1024 samples for the buffer.

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.

[John_E]

@John_E

With Ardour 9 or Mixbus 11 I see it predictably on Windows (both my builds and Robin’s)

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???

I’m totally confused

[chiraag-nataraj (ಚಿರಾಗ್ ನಟರಾಜ್)]

@John_E

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?

[John_E]

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

[hodger]

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.

h