Audible click/pop when audio bus changes

[ArdaE]

When an Area2D is used to divert audio to a different bus than the currently active one, occasionally there's an audible click.

I haven't tried other ways of changing the bus (other than the automatic Area2D-based diversion), but I'm guessing this issue is likely present in all of them. I have tried both .ogg and .wav files for the audio, with the same results.

Here's my guess of what the issue might be:
Any unnaturally large change in the amplitude of audio samples over a single sample period is bound to cause clicks/pops due to the extreme frequencies that will be introduced during such sudden change. So I'm guessing Godot may currently be using a naive (easy to implement) approach that changes busses suddenly, over a single sample period. This would almost always produce a click unless the output of the two busses match both in time and in amplitude; however the audibility of the click would depend on the amplitude of the change, which we can consider to be random for all practical purposes (so it would sometimes be audible and sometimes not, and it would occasionally fit in with the audio being played and not be noticeable).

Possible solutions (assuming my guess about Godot's current implementation is correct):
An obvious solution would be to apply a low-pass filter during bus transitions, i.e. smooth out any transition. Even a simple smoothing operation over a few sample periods should work wonders (e.g. a simple solution that overlaps the new and old busses for a few samples, during which it fades out the old bus and fades in the new one). Alternatively, a simple low-pass filter that is faded in and then faded out* during the transition period would eliminate the need to run two busses in parallel, and thus have constant (and usually much lower) CPU overhead that is independent of the busses in use. The latter would also be easier to control if a new bus transition is needed while one is in progress, unless the system applies some delay to consecutive bus changes to avoid multiple overlapping transitions.

• The fade-in, fade-out of the filter in the second solution is to avoid introducing high-frequencies due to the sudden introduction of the filter itself.

Further information:
To test/reproduce this issue, make sure the busses you use apply different effects, and make sure your audio is not silent. To almost guarantee a click most of the time, simply lower the volume of one of the busses significantly or use any effect that causes a time-delay.

Last tested on Godot version 3.0.6, but the issue was there in the first 3.0 release as well.
OS: macOS 10.13.6

Bugsquad edit (keywords for easier searching): crack, cracking

[marcelofg55]

Could you provide a test project for this? Thanks

[ArdaE]

Here you go; test project attached (I had to find a public domain audio file).

Enable "Visible Collision Shapes" under the Debug menu, run project, and use the cursor keys to move the icon in and out of the circle. Pay attention to the clicks as the icon crosses the area's border.

Godot Audio Click.zip

Edit: The included song18 music is credits to "pixelsphere.org / The Cynic Project", and can be found here, where it's currently listed as "CC0" / "Public Domain".

[akien-mga]

Still reproducible in 3.1-stable and 9984ebb.

[KoBeWi]

Still valid in 3ed5ff2

[akien-mga]

Still reproducible in 3.3-stable and latest master (f879a08).

[jjmontesl]

If this is still failing on latest stables and master, after @ellenhp changes, I'd suggest trying my dodgy branch to see if it fixes it:

https://github.com/jjmontesl/godot/tree/3.2.3-stable-audio-effects-nan-sanity-check

IF it fixes it or helps, this would then be related to #28110 and the related family of issues. Also possibly to proposal godotengine/godot-proposals#2299 .

[ellenhp]

Yeah unfortunately I never addressed this issue since there's no real way to do so without adding ugly bus fading logic in all four audio player nodes or doing something similar to what I described in that proposal I made. This issue isn't caused by NaNs as far as I know, it's just that there's no fadein/fadeout on bus changes so there's a discontinuity introduced at the moment the bus is switched.

I tried to begin implementing that proposal but I ran into issues since reduz doesn't want to add thread-safe Refs to the engine and I can't think of any other ways to build a non-blocking thread-safe data structure in Godot. I think that might effectively stop that proposal in its tracks unfortunately. I'm no longer interested in working on it given how hard it is to get bugfixes accepted in this project. I recognize the value in having a high bar but I'd prefer to work on other things if there's such a high chance of being told no.