Get rid of switching Audio GAPs p3/6 - Technical measurements and info

BobXX

Inspired
[ Part 1 here - Measurements and Info ]
[ Part 2 here - Measurements and Info ]
[ Part 3 here - Measurements and Info ] current
[ Part 4 here - Tips & Tricks ]
[ Part 5 here - Tips & Tricks ]
[ Part 6 here - Tips & Tricks - GAP "FILLER": GAPLESS Proof of Concept ]


Looking at the risults, you might think that adding two "gap inducting" blocks in series you will get the double of audio gap:
this is not true !

In most cases the gap won't increase significantly
, it does with a non-linear behaviour. For some reason certain blocks just "trigger" a gap, that changes significantly only in some conditions we are going to see now.

Take this Preset:
  • row 1 and 2 are made with gapeless blocks (1 x each of them)
  • row 3 and 4 are made with all the remaining "gap inducing" blocks

2023-07-09_20h10_51.png

I just placed 2 AMPS because in my real presets (this is just for testing) I use 1 AMP for rock/metal distorsions (since I can't use any of the DRIVEs), the second AMP/CAP to go to FOH. See my Wish here.

If I switch ALL the block's channels and, when possible, even their type (that's an absolutely extremely crazy case),
I got 25ms reaction delay and a 120ms gap:

SDS00350b.png
NOTE: this image is "zoomed out", every division means 20ms

You might think that this is the sum of each block's gap listed in Part 1... it isn't, that sum is 220ms.
This confirms that - when induced - the amount of gap doesn't increase linearly.

But let us see what happens if - in the same last case - I just don't switch MEGA TAP DELAY's channel among other 32 blocks that I keep switching their channels simultaneusly...
Gap narrows to 95ms (-25ms -20% !):

SDS00351b.png

So I discovered that switching to MEGA TAP DELAY - Type "Reverb Pre-Swell" adds ~25ms gap on its own.

We will see later that few blocks acts this way whilst the majority of the blocks nearly don't increase the gap, even the "gap inducing" ones or not.

So, as partially said before:
  • if I switch channels of row 1 and 2 (gapless ones), I have no gaps (even switching that META TAP DELAY...)
  • if I switch just 1 "gap inducting" more, the audio gap appears,
    and its amount is influenced by other "gapless" or not blacks where I change the channel simultaneously, especially some of them
  • blocks that don't change the channel, don't influence the final gap

  • NOTE: all these measurements are done carefully keeping CPU load below 80%. I can confirm that above that limit the system performances decrease very rapidly, including Reaction Delay and Gaps.

To understand more, in the same chain above, let's always keep 1 AMP channel switch, and change settings of the other blocks to see what happens:
TEST
GAPLESS BLOCKS
(rows 1 and 2)
GAP INDUCTING BLOCKS
(rows 3 and 4)
REACTION DELAY
(ms)
GAP
(ms)
GAP increase
(ms)
1no channel changesReference (channel switched of only AMP1 - Type "RECTOxxxxx)2838reference
2ALL changed
with the exception of
META TAP DELAY and
TEN TAP DELAY
no channel changes2848+10
3no channel changeschannel changes for CHORUS + COMP+ DRIVE
+ DYNDIST + FILTER + GEQ + IRPLAY + PEQ + PHASER
2845+7
4no channel changesALL changed2585+47
5ALL changedALL changed28120+82

Comparing first and second test, you see that switching 20 channels more, just increase gap of only 10ms.
Comparing first and thirds test, adding 9 channels switches for gap inducting channels the increase is only 7ms.

Let's discover the blocks more "guilty" of increasing gap.

The measurements are done with the same Preset, always keeping AMP1 channel switch, and adding only 1 block channel change:
TEST
GAP INCREASING BLOCK/TYPE added
REACTION DELAY
(ms)
GAP
(ms)
GAP increase
(ms)
1Reference (channel switched of only AMP1 - Type "RECTOxxxxx)2538reference
2+ AMP2 - Type "RECTOxxxxx"2562+24
3+ CAB - Type "DYNA CAB"2552+14
4+ CAB - Type "LEGACY"2545+7
5+ MULTI DELAY2848+10
6+ TEN TAP DELAY - Type "TEN TAP DELAY"2856+18
7+ TEN TAP DELAY - Type "RHYTHM TAP DELAY"2843+5
8+ MEGA TAP DELAY - Type "REVERB PRE-SWELL"2865+25
9+ MEGA TAP DELAY - Type "DECEPTICONS"2842+4
10+
AMP
CAB (Dyna)
2875+37 (~ 24+14)
11+
AMP
CAB (Dyna)
MULTIDELAY
TEN TAP DELAY
MEGA TAP DELAY (Reverb)
28120+82

We expected major increases with AMPs and CABs, due to their complexity.
Not the same for the others.
We can see that among nearly "innocent" blocks there may be some TYPE of them that could be guilty in increasing gaps a lot.
  • Obviously I haven't tried all the block types
    If someone find a Block/Type suspected to act the same pls. tell me, I'll test it

  • Tests 10 and 11 reveals that every channel change added for those "guitly" blocks, will widen the gap of about the individual increase shown in the table above

Looking at these figures, I was courious to try to switch an identical entire Preset, one with al channels set to A and the other with all channels in B... the resulting gap is 70ms!
So in the case we expect a gap bigger than 70ms, it's convenient to switch the entire Preset instead of a Scene.

Let's start with the funny parts, tip and tricks:

[ Part 4 here - Tips & Tricks ]
 

Attachments

  • SDS00342b.png
    SDS00342b.png
    18.3 KB · Views: 64
  • SDS00351.png
    SDS00351.png
    55.8 KB · Views: 6
Last edited:
Just a note that your preset shows 82% CPU and has a red warning indicator.

You're in the danger zone and this might impact your results.

I understand what you're trying to do and it's interesting, but there may be extenuating circumstances for the tests.

Try testing with CPU below 80% (the recommended max load).
 
Just a note that your preset shows 82% CPU and has a red warning indicator.

You're in the danger zone and this might impact your results.

I understand what you're trying to do and it's interesting, but there may be extenuating circumstances for the tests.

Try testing with CPU below 80% (the recommended max load).

Thank Unix-Guy, you're right,

in parts 2 and 3 I have done again and updated the measurements where CPU were >= 80%, reducing reverb quality or shunthing blocks not involved in the test, see below.
I left unchanged the first test in part 2 to underline that even at 82% CPU there were no gaps.

Doing this I can conferm that from 80% and above performances decreases rapidly, so your your pointing is doubly right.

2023-07-09_21h59_44.png
 
Back
Top Bottom