CLASH_THRESHOLD_G setting not "working"

ProffieOS
22

What if you add

#define AUDIO_CLASH_SUPPRESSION_LEVEL 1

The default is 10, which is fairly low, but even a low audio clash suppression level could be significant compared to a clash threshold of 0.5.

1 Like
23

I’ll try 1, 10, 20, 50.

On a separate note, do you think I should try rolling back to ProffieOS 6.9?

24

Not really, but it can be interesting to compare.

25

That worked! CLASH_THRESHOLD_G 0.5 and AUDIO_CLASH_SUPPRESSION_LEVEL 1 is just right.

Thanks so much. What do you think the issue is? I’ve tried lowering the volume to min, thinking it was speaker interference and that didn’t fix it.

26

Ok, so there are multiple things going on here.

  1. AUDIO_CLASH_SUPPRESSION_LEVEL uses the volume level calculated by the dynamic compressor. However, this happens before the final volume adjustment, which is probably not how we actually want it to work, because that means that if your volume is low, the adjustment is too high, and if your volume is high, the adjustment is too low.
  2. AUDIO_CLASH_SUPPRESSION_LEVEL is independent of CLASH_THRESHOLD_G, which is probably also not what we want. The default value ends up increasing CLASH_THRESHOLD_G by about 1 when a loud font is playing. For someone who has a CLASH_TRESHOLD_G set to 5, changing it to 6 makes a fairly small difference. For someone who has CLASH_THRESHOLD_G set to 0.5, it makes a huge difference. AUDIO_CLASH_SUPPRESSION_LEVEL should probably be a multiplier instead.
  3. It’s weird and and unusual to set CLASH_THRESHOLD_G as low as 0.5. I’m not sure why such a low value works well for you, but doing so is what exposed the problems with the AUDIO_CLASH_SUPPRESSION_LEVEL.
1 Like
27

Just had a case of this exact problem (no clashes without smashing something to death even down to CLASH_THRESHOLD_G 0.1)
Didn’t go through serial monitoring troubleshooting steps, just cut to the chase and added the suppression define and it “fixed it”. Then needed to up the threshold to ~2.0 to dial in normal clashing.
So the question is… why?
Do the statements above about “probably not how we actually want it to work” mean some code still could use some tweaking?
This was a v3.9 board btw.

28

FWIW if this helps neither of my V3’s is affected. Running these in defines

#define VOLUME 2200
#define CLASH_THRESHOLD_G 4
#define AUDIO_CLASH_SUPPRESSION_LEVEL 5

Note that aside from my upping the volume w the V3 configs the defines are the same as they are w the kids and my V2 boards.

29

but does it NOT work if you comment out the audio suppression define?

30

At the very least, we should scale AUDIO_CLASH_SUPPRESSION_LEVEL by the clash threshold.

31

@NoSloppy I can certainly put in some time tomorrow or Saturday night and give it a go if you want. The thing is with the PowerCore setup I can’t run the cable to pull Serial Monitor output. I could disable blade detect and just bench test the core with Diagnostic Commands active.

:+1:

32

Don’t need seriall monitor info really. Just curious if you remove that define if clashes become next to impossible.

33

Got ya. I’ll get to testing by Saturday night and post an answer.

34

One additional point of clarity so I can test whatever else besides just disabling the suppression define.

What prop(s) are in use when this is being seen? I’m on Fett263’s prop and haven’t seen it but will be testing thru Sunday.

35

Fett263. But try others too.

36

I’m wrapping up testing three sabers. Two with a V3.9 board and another with a V2.2 board. Not seeing this glitch. Zero issues with Fett263’s or NoSloppy’s props. This is the CONFIG if anyone wants a look.

Maybe we should be asking what specific boards are showing this as it may well be manufacturer’s component spec affecting things. **JustSaying

MTFBWY!

*Update: I went ahead and borrowed a couple other V2.2’s and a V3.9, none of them show the glitch.

37

Ok thanks.