GSCapture: add volume slider and scale recorded audio

[SternXD]

Description of Changes

Fixes #12700

• Added an audio capture volume slider
• Made a new AudioCaptureVolume setting stored in GS config, defaulting to 80%.
• Applied the volume multiplier when feeding samples to the FFmpeg encoder

Originally I was going to add libavfilter but I couldn't justify adding that library for one feature so that's why I did this the way I did.

Rationale behind Changes

Giving users a volume control makes built-in recording behave more like standard capture tools where mic/system levels can be balanced before hitting "Record."

Suggested Testing Steps

• Start a capture with default settings, then inspect the resulting video to confirm the recorded audio is quieter than before.
• Change the slider to e.g. 50% and 100%, capture again, and confirm the output volume scales accordingly for the video capture

Did you use AI to help find, test, or implement this issue or feature?

No.

[TheTechnician27]

If you wanted to, in theory, you could get away with:

for (u32 j = 0; j < this_batch; j++)
{
	const s16 scaled_input = volume_scale == 1.0f ? *input :
		static_cast<16>(std::clamp(static_cast<float>(*input) * volume_scale, -32768.0f, 32767.0f));

    std::memcpy(output, &scaled_input, sizeof(s16));

	input += AUDIO_CHANNELS;
	output += s_audio_frame_bps;
}

else if that ternary is too gross:

for (u32 j = 0; j < this_batch; j++)
{
	if (volume_scale != 1.0f)
	{
		const s16 scaled_input = static_cast<16>(
			std::clamp(static_cast<float>(*input) * volume_scale, -32768.0f, 32767.0f)
		std::memcpy(output, &scaled_input, sizeof(s16));
	}
	else
	{
		std::memcpy(output, input, sizeof(s16));
	}

	input += AUDIO_CHANNELS;
	output += s_audio_frame_bps;
}

(In the second one, you could eliminate the else by just having scaled_input be the name for both branches, but that seems more confusing. Like so:)

for (u32 j = 0; j < this_batch; j++)
{
	s16 scaled_input = *input;
	if (volume_scale != 1.0f)
	{
		scaled_input = static_cast<16>(
			std::clamp(static_cast<float>(scaled_input) * volume_scale, -32768.0f, 32767.0f)
	}
	std::memcpy(output, &scaled_input, sizeof(s16));

	input += AUDIO_CHANNELS;
	output += s_audio_frame_bps;
}

TL;DR is that using std::clamp() like you do later on would cut down on verbosity here.

[SternXD]

Alright I think I made it a lot better

[TheTechnician27]

For something that's probably going to be running quite frequently, this seems like something you would want to call volume_buffer.reserve(n) for rather than volume_buffer.resize(n). The latter will zero-initialize the values for, in this case, no good reason. (You can also safely declare it inside the volume_scale != 1.0f condition, since it's not used anywhere else.)

I don't assume you're allowed to overwrite the original s_audio_buffer while doing this, as that would arguably be the most efficient way.

[chaoticgd]

I'm not familiar with the code, but I just want to flag up that you need to be really careful with std::vector::reserve since it defeats std::vectors default behaviour of doubling (or similar) the size of the memory buffer every time it needs to grow. Hence it makes it have to reallocate every single time, which can kill performance.

[chaoticgd]

Reading more of the code, it looks like it won't be a problem in this case since it's only called once.

[TheTechnician27]

I'm not familiar with the code, but I just want to flag up that you need to be really careful with std::vector::reserve since it defeats std::vectors default behaviour of doubling (or similar) the size of the memory buffer every time it needs to grow. Hence it makes it have to reallocate every single time, which can kill performance.

In this case, the vec is being initialized and then resized to exactly the size it needs to be once per call of ProcessAudioPackets() should this branch be taken. So it should only ever grow one time, and thus it should be the same or faster in all cases.

Edit: Honestly, it's functionally an array, whose allocation might be more efficient.

[chaoticgd]

Yea I missed that it was being reallocated for every loop iteration the first time I looked.

[SternXD]

alright so I just pushed changes that should resolve some of the suggestions like the don't clamp mention in the discord for example

[kamfretoz]

Latest changes seems to cause crackling on the audio.

Crash.Twinsanity_SLUS-20909_20251201215551.mp4

My capture settings:

[SternXD]

Latest changes seems to cause crackling on the audio.

Crash.Twinsanity_SLUS-20909_20251201215551.mp4
My capture settings:

Oh yeah, yikes let me go ahead and try to fix that.

[F0bes]

If the PR is not in a reviewable state please draft it. I just spent time looking at the code to find that it needs to be changed 💔

[SternXD]

If the PR is not in a reviewable state please draft it. I just spent time looking at the code to find that it needs to be changed 💔

Sowy I forgor

[SternXD]

Rebased

So I don't forget this is what I need to fix:

• Fix crackling when turning the volume up and down while recording