libobs: Cleanup local names in obs-audio-controls

[ansh1406]

Description

Updated libobs audio control internals in obs-audio-controls.c with non-functional cleanup changes:

• Renamed short local variables to clearer names (for example, cb to fader_callback or meter_callback, and r to peak_value).
• Normalized float literals to single-precision style (0.0f).
• Added explicit initialization for local float variables used in the touched code paths.

No public API signatures or observable behavior were changed.

Motivation and Context

This change improves readability and consistency in a hot-path file that handles fader and volmeter internals. Clearer local names reduce review and maintenance overhead, and explicit float style and initialization make intent more obvious.

This PR does not target a specific open issue.

How Has This Been Tested?

• Reviewed the full git range diff for 63962b6..HEAD.
• Verified changes are limited to libobs/obs-audio-controls.c.
• Verified no function signatures, struct layouts, or public interfaces were modified.

Testing environment:

• OS: Windows
• Repository: local obs-studio checkout

Note: No runtime/audio pipeline execution tests were run for this cleanup-only change.

Types of changes

• Code cleanup (non-breaking change which makes code smaller or more readable)

Checklist:

• I have read the contributing document.
• My code has been run through clang-format.
• My code follows the project's style guidelines
• My code is not on the master branch.
• My code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Fenrirthviti]

Can you please explain why you felt these changes were necessary, what did you use to determine that, and why you haven't tested them?

You are changing variables around, and this should always be tested regardless of how "simple" a change might seem.

Additionally, you have not completed the PR checklist. Why have you skipped some steps on submission?

[ansh1406]

I won't say they are totally necessary. I read CODESTYLE.MD file and found some inconsistencies so I fixed them while ensuring their influence will be contained within the file itself.

I did not change variables, I just renamed local variables whose scope was limited to few lines. Or initialized them if they were not as mentioned.

For the PR checklist , there was no documentation needed , I was not quite sure how finely my commits should be divided.

[ansh1406]

Clang format check is done ✅

[ansh1406]

Should I squash them all in single commit ?

[Fenrirthviti]

These commits are suspiciously similar to what an AI would write. Can you confirm if any AI tooling was used to discover/write this PR?

[ansh1406]

I did used AI help to write the pr description, but not in the code

[PatTheMav]

My immediate reaction here would be to ask "what is the difference between peak and peak_value?" which suggests that the name of the former is too ambiguous here.

[ansh1406]

Yes previously I did not look into it deeply , I've improved it now. I also improved it in get_true_peak.

Now they should have better readability.

[ansh1406]

Also I found a bug ,

static float get_sample_peak(__m128 previous_samples, const float *samples, size_t nr_samples)
{
	__m128 max_abs_per_lane = previous_samples;

and

static float get_true_peak(__m128 previous_samples, const float *samples, size_t nr_samples)
{
	/* These are normalized-sinc parameters for interpolating over sample
	 * points which are located at x-coords: -1.5, -0.5, +0.5, +1.5.
	 * And oversample points at x-coords: -0.3, -0.1, 0.1, 0.3. */
	const __m128 sinc_minus_03 = _mm_set_ps(-0.155915f, 0.935489f, 0.233872f, -0.103943f);
	const __m128 sinc_minus_01 = _mm_set_ps(-0.216236f, 0.756827f, 0.504551f, -0.189207f);
	const __m128 sinc_plus_01 = _mm_set_ps(-0.189207f, 0.504551f, 0.756827f, -0.216236f);
	const __m128 sinc_plus_03 = _mm_set_ps(-0.103943f, 0.233872f, 0.935489f, -0.155915f);

	__m128 sample_window = previous_samples;
	__m128 max_abs_per_lane = previous_samples;

in these both instances max_abs_per_lane should initialize with absolute value of previous_samples

Should I fix it in this PR with updated title or in different PR, since it's named as cleanup?

[PatTheMav]

Given the different "blast" radius that should probably be a separate PR.

I'd suggest opening a new PR with just the suggested fix (but the old names) and then re-base this PR on top of that fix with all the name changes.

If we merge the bugfix PR, then rebasing this PR will automatically remove it from the change set and the "type of changes" are neatly separated.