Problem with audioNode.setDryFilter(LowPassFilter) in test class TestPostWater

[capdevon]

I opened this issue to keep track of the discussion on the forum.
https://hub.jmonkeyengine.org/t/question-about-com-jme3-audio-lowpassfilter/45164

It appears that the LawPassFilter has no effect on the audio node. I didn't understand if the problem is on the node or on the filter. The problem is present in the test class TestPostWater

[bob0bob]

This is not the case. It is because they use Reverb on the audio node and the dryFilter will not alter the volume or pitch when reverb is on. So in this sample, it is wrong, because it doesn't work when it comes to hearing. Even though it is working and alters the original sound not the reverb.

Going under water should turn off the reverb, in this sample to be more correct.

But again for me, doing a NEW on a class every update is a HUGE waste of memory and causes unwanted garbage collection. The DryFilter should be a field and then you just assign 2 different dry filters to this method instead of every frame update creating a new class.

[pspeed42]

The code isn't creating a new one every time. Only when the state changes from one side of the water to the other.

...they could still be kept around but it's not as bad as every frame. In a real game, this should be managed with an app state or something.

[bob0bob]

Overall there is a bug in this example because going under water make no difference because of reverb. Reverb should be turned off when going under water for a better example of what to do.

If everyone agrees, I'll change it to turn it off under water.

[stephengold]

While I don't speak for everybody, I'm fine with turning off reverb underwater.

[bob0bob]

I"ll get it changed and submit a pull request.

[stephengold]

After further testing, I'm convinced there's a library issue here that #1707 doesn't really solve.

I understand that the dry filter isn't supposed to have any effect when reverb is enabled. But even with reverb disabled, AudioNode.setDryFilter() has a perceptible effect only the first time it is invoked. The 2nd and successive invocations seem to have no effect. That suggests a bug in ALAudioRenderer, and I believe I've found one:

                    if (src.getDryFilter() != null) {
                        Filter f = src.getDryFilter();
                        if (f.isUpdateNeeded()) {
                            updateFilter(f);

                            // NOTE: must re-attach filter for changes to apply.
                            al.alSourcei(id, EFX.AL_DIRECT_FILTER, f.getId());
                        }
                    } else {
                        al.alSourcei(id, EFX.AL_DIRECT_FILTER, EFX.AL_FILTER_NULL);
                    }

If the filter has changed and the new filter doesn't need updating, alSourcei() is never invoked. I think the logic ought to be something like:

                    if (src.getDryFilter() != null) {
                        Filter f = src.getDryFilter();
                        if (f.isUpdateNeeded()) {
                            updateFilter(f);
                        }
                        // NOTE: must re-attach filter for changes to apply.
                        al.alSourcei(id, EFX.AL_DIRECT_FILTER, f.getId());
                    } else {
                        al.alSourcei(id, EFX.AL_DIRECT_FILTER, EFX.AL_FILTER_NULL);
                    }