The starting point for this was when I switched the order of two mixer tracks and
observed the FL cpu metric / buffer processing time going down by ~15%.
First I couldn't believe it, but found it to be recreatable when switching back and forth.
I have checked the documentation and forum, but it was mainly about the
overall complexity of the signal paths and the depth of send chains,
which should not be affected by simple track order.
Test setup:
The setup contains two level 1 source tracks a+c,
and two level 2 send tracks b+d, like subgroups
NOT being the global buses 100-103.
a+c are not routed to the master.
b+d are routed to the master.
a+c do not contain insert fx.
b+d do contain cpu relevant fx chains.
Send levels to global buses 100-103 are all zero.
In A) the channels are ordered by relation.
In B) the channels are ordered by level.
A) Order with higher cpu metric
Code: Select all
Tracks
1 2 3 4
Channels
a b c d
| | | |
-->-- -->--Code: Select all
Tracks
1 2 3 4
Channels
a c b d
| | | |
-->-|---- |
-->------A1)
Mixer threading map rebuilt: 5 layer(s)
Layer 1: 1 unit(s)
-Unit 1: track(s) 1
Layer 2: 1 unit(s)
-Unit 1: track(s) 2,3
Layer 3: 1 unit(s)
-Unit 1: track(s) 4,5,6,7,...,99
Layer 4: 1 unit(s)
-Unit 1: track(s) 100,101,102,103
Layer 5: 1 unit(s)
-Unit 1: track(s) 0
B1)
Mixer threading map rebuilt: 4 layer(s)
Layer 1: 1 unit(s)
-Unit 1: track(s) 1,2
Layer 2: 2 unit(s)
-Unit 1: track(s) 3
-Unit 2: track(s) 4,5,6,7,...,99
Layer 3: 1 unit(s)
-Unit 1: track(s) 100,101,102,103
Layer 4: 1 unit(s)
-Unit 1: track(s) 0
At this point I would kindly ask somebody from the dev/tech team to
join and comment and the following conclusions and guesses.
Our track order seems to affect the number of layers.
If we extend the above setup to 4 source tracks
and 4 send tracks things are getting even more significant.
A2)
Mixer threading map rebuilt: 7 layer(s)
Layer 1: 1 unit(s)
-Unit 1: track(s) 1
Layer 2: 1 unit(s)
-Unit 1: track(s) 2,3
Layer 3: 1 unit(s)
-Unit 1: track(s) 4,5
Layer 4: 1 unit(s)
-Unit 1: track(s) 6,7
Layer 5: 1 unit(s)
-Unit 1: track(s) 8,9,10,...,99
Layer 6: 1 unit(s)
-Unit 1: track(s) 100,101,102,103
Layer 7: 1 unit(s)
-Unit 1: track(s) 0
B2)
Mixer threading map rebuilt: 4 layer(s)
Layer 1: 1 unit(s)
-Unit 1: track(s) 1,2,3,4
Layer 2: 4 unit(s)
-Unit 1: track(s) 5
-Unit 2: track(s) 6
-Unit 3: track(s) 7
-Unit 4: track(s) 8,9,10,...,99
Layer 3: 1 unit(s)
-Unit 1: track(s) 100,101,102,103
Layer 4: 1 unit(s)
-Unit 1: track(s) 0
In absolute numbers the FL cpu metrics were
A2: 53%
B2: 20%
A huge difference.
Keep in mind that only the track order changed.
Trying to understand what layers and units are I came to:
Layers are time boxes that are processed in series,
leading to the buffer processing time of the layers summing up.
Units are processing tasks that inside the same layer
can be processed in parallel. Even if they may not exactly be threads
they can be thought as such.
Looking at A2/B2 we can see that in A2 our cpu consuming
tracks 2,4,6,8 are attached to different layers and therefore
are processed in series.
In B2 our cpu consuming tracks 5,6,7,8 are processed
in different units inside the same layer, in parallel.
Obviously B2 has the better multi-core utilization.
So would it be possible the mapping algorithm taking care
of this instead of me reordering tracks? I think so.
My proposal is to add some minimal logic to the mapping
algorithm which is checking the signal flow level of each track
prior to mapping them into layers.
As long as this is not available, detailed documentation
might help users to avoid unfavorable mappings.