Fix Capture and Record AudioEffect bugs for surround systems

[BuzzLord]

The AudioEffectCapture and AudioEffectRecord classes do not work properly when there is more than one audio channel active. This PR makes some changes to several AudioEffect classes to fix these bugs. Fixes #91133.

I added set_current_channel to AudioEffectInstance to keep AudioServer::_update_bus_effects clean, since I wanted that functionality for capture and record. It was already part of compressor, and seems like something that could be useful for other effect instances if they needed it. The default implementation is a no-op.

Added an active_channel property to both AudioEffectCapture and AudioEffectRecord. Capture uses it to return early from process so that only the active instance writes data to the buffer.

Record now stores all instances (that are registered) by channel, and when changing the active_channel, it changes the internal current_instance to reflect that.

The active_channel property is exposed in the editor for both classes. It doesn't currently update the available drop-down options to reflect the actual number of channels available in the AudioServer. The set_active_channel functions also don't explicitly check for the validity of the p_channel args, but they do work with invalid inputs (it just disables capture/recording).

[AThousandShips]

Suggested change

	virtual void set_current_channel(int p_channel) {};
	virtual void set_current_channel(int p_channel) {}

For format check

[BuzzLord]

Fixed. Also added virtual to compressor and capture set_current_channel (I received email suggestions for these, but don't see them on github). I didn't add it to record as its set_current_channel is a bit more nuanced, and if someone wants to override it, they can refactor it at that time.

[AThousandShips]

We always add both, not adding it won't stop overriding later you need final for that

[BuzzLord]

Fair enough.

[BuzzLord]

Is anyone able to take a look at this? I can appreciate it might be hard to test without an affected audio setup. I have a (crude) change to the Audio Dummy Driver that could help with testing, if the audio setup is too much of an issue. The change just exposes the speaker mode as a configurable parameter when the dummy driver is active in the editor.

[Mickeon]

Letting the tests run.
There's very few maintainers that are keenly aware of the audio side of Godot so this may take a while to be taken a look at.

[OpenFormEon]

Is anyone able to take a look at this? I can appreciate it might be hard to test without an affected audio setup. I have a (crude) change to the Audio Dummy Driver that could help with testing, if the audio setup is too much of an issue. The change just exposes the speaker mode as a configurable parameter when the dummy driver is active in the editor.

I have a game where the entire gameplay is recording and playing back audio via AudioEffectRecord from players' microphones, and many players have reported that the recording doesn't work. Input is working, because they can hear themselves when the bus isn't muted and AudioEffectSpectrumAnalyzer works just fine. Only the recording is failing. Do you think my game's issue could also be due to the bug you describe? If so, what's the best way to try out your fix in my version of Godot? Apologies, I'm unfamiliar with both Github and how to change the Godot Engine's own code.

[Nihlus]

I'm also experiencing this - as long as the output is a stereo 2.0 channel, recording works fine, but any HiFi / Surround configuration makes AudioEffectCapture unusable for my use case (speech to text).

[BuzzLord]

I have a game where the entire gameplay is recording and playing back audio via AudioEffectRecord from players' microphones, and many players have reported that the recording doesn't work. Input is working, because they can hear themselves when the bus isn't muted and AudioEffectSpectrumAnalyzer works just fine. Only the recording is failing. Do you think my game's issue could also be due to the bug you describe?

I do think this is the bug. AudioEffectRecord only records from the last channel (because of the bug), which on anything more than a stereo system will be silent (microphones normally only record stereo to the first channel). This should fix it.

The SpectrumAnalyzer is one of the only effects that is channel aware, which is why it works. You select the effect instance (which is per-channel) with AudioServer.get_bus_effect_instance(bus, effect), but there's a third channel argument that defaults to 0 (the main stereo channel).

If so, what's the best way to try out your fix in my version of Godot? Apologies, I'm unfamiliar with both Github and how to change the Godot Engine's own code.

Unfortunately I'm new here too, and am not sure what the best way to test would be. I setup a dev environment to build and test my own releases, but I don't think sharing executables is the way to go. Maybe one of the main contributors can chime in.

I'm also experiencing this - as long as the output is a stereo 2.0 channel, recording works fine, but any HiFi / Surround configuration makes AudioEffectCapture unusable for my use case (speech to text).

If this is the bug, the audio should sound very garbled and static-y. A work around I use in my own project (in GDScript) is to pull frames from the capture buffer in chunks of 512. Then before passing that array on, I loop over it, and check that both channels of every frame is exactly equal to 0.0. If so, I skip that chunk. This works because the AudioServer processes 512 frames at a time, per channel, so your good data should be in amongst 512 frame chunks of silence.

[BuzzLord]

@OpenFormEon I was looking at the Godot Contribution Workflow docs and see that you can download the editor with this PR applied for testing, once the workflow/tests are run on it again, or by using the nightly.link website. Details available here.