SPU2: Fix interface for output muting

[TheTechnician27]

Description of Changes

SPU2

• Fixes [BUG]: 'Toggle Mute' hotkey un-mutes when fast-forwarding if the output volume and fast-forward volume differ #13168.
• Implements a s_output_muted variable in SPU2 (with accessor) which tracks whether the SPU2 is or isn't muted through EmuConfig/hotkey.
• Implements s_standard_volume and s_fast_forward_volume variables in SPU2 which track the current volume level of each "channel" in parallel. This maintains the user's choices such as hotkey volumes and volume slider changes throughout the session.
• Implements a SetOutputMuted() function in SPU2 which sets unmute volume, sets output muted status, and changes the volume correspondingly. Potential future means of muting the SPU2 can make easy, elegant use of this.
• More clearly establishes that EmuConfig.SPU2.OutputMuted takes absolute precedence over e.g. hotkeys.
• Deletes two unused functions in QtHost.cpp.
• Renames OutputVolume to StandardVolume. "Output volume" was overloaded, likely as a product of it existing before FastForwardVolume. This works better from a user-facing end because it's more clear ("Standard Volume" and "Fast Forward Volume", opposed to "Output Volume" and "Fast Forward Volume") and especially from a maintenance one because we'll have two separate terms for two separate concepts – where one means the current volume of the VM regardless of speed, and the other means the standard-speed volume the user has set.

OSD

• Volume-adjusting hotkeys now have message "Volume: Increased/Decreased to N%" or "Volume: Maximum/Minimum N% Reached". Because 5% is a small difference, this provides more continuity than just announcing the new volume.

• Mute toggle hotkey now has a message "Unmuted to N%" when unmuting. This is again better for continuity.

• The volume icon now shows ICON_FA_VOLUME_OFF when at 0% (not muted; see above).
• Additionally, the volume icon when unmuting will be ICON_FA_VOLUME_OFF when 0%, ICON_FA_VOLUME_LOW when < 100%, and ICON_FA_VOLUME_HIGH otherwise.
• Informs the user why hotkey won't unmute if EmuConfig setting is on. Currently just says "Muted" over and over again.

I was unable to add an OSD message when toggling the Mute All Sounds setting. Running from the Qt settings widget is a no-go without linking it to things like the FA icons, which is overkill, and running from inside the SPU2 seems inappropriate.

Rationale behind Changes

SPU2

The way we dealt with muting in SPU2 was fundamentally broken with the exception of the EmuConfig setting.

The hotkey conflated setting volume to 0% with toggling a mute. Because this is all the hotkey did, literally anything that wanted to change the volume would override it, including a switch between speeds. The mute hotkey using the same function as the volume adjust hotkeys reinforced this paradigm. The volume adjust hotkeys still override the mute, as that is standard, expected behavior for a mute button.

In current master, if you toggle mute on at a non-default volume (e.g. adjusted via hotkeys) and then back off, you would be reverted to whatever preset you have in the settings. This obviously isn't intuitive or convenient behavior. It likewise isn't intuitive that if you have your standard volume at, say, 70%, change to fast forward, and then back, it'll return to whatever you had in the slider rather than the actual volume.

OSD

Just gives a bit more what I call "continuity", which helps the user more immediately understand the state of the volume.

The changes at the bottom of spu2.h were just clang-format doing its thing. 🤷

Suggested Testing Steps

• Make sure [BUG]: 'Toggle Mute' hotkey un-mutes when fast-forwarding if the output volume and fast-forward volume differ #13168 is fixed.
• Make sure the OSD messages appear correctly.
• Make sure that muting with the Mute All Sounds button (on startup and during a VM session) and the mute hotkey both work correctly and don't break when you do weird stuff with them, the volume sliders, and the volume adjust hotkeys.

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

I created an Audio Interface (AI).

[TheLastRar]

Had a brief look at the code, looks okay assuming I've not missed anything

However, can someone check what happens in the following situations

User mutes via hotkey (which also saves the current volume)
User adjusts volume down in settings
User returns and unmutes
Is the new setting volume applied, or the volume that existed before muting?

User has different volumes for normal and fast forward
User starts fast forward
User mutes during FF section
User stops FF
User unmutes, is the volume set to the normal or FF volume?

User has different volumes for normal and FF speed
User adjusts volume via Hotkeys
User enters or exit FF
What should happen to the volume?

[TheTechnician27]

User mutes via hotkey (which also saves the current volume) User adjusts volume down in settings User returns and unmutes Is the new setting volume applied, or the volume that existed before muting?

New volume is not applied. This is handled by EmuThread::setAudioOutputVolume in QtHost.cpp, and I can fix it.

User has different volumes for normal and fast forward User starts fast forward User mutes during FF section User stops FF User unmutes, is the volume set to the normal or FF volume?

Same as the first, although this one is even easier to fix because the SPU2 runs a function on nominal rate change. If muted, it could just change the restore volume to whatever the default is for that rate.

User has different volumes for normal and FF speed User adjusts volume via Hotkeys User enters or exit FF What should happen to the volume?

This part isn't affected by the mute system improvements, but it works as it always would. I think if, say, the user has 100% standard and 60% FF, but they're on FF and set it to 40%, instead of trying to take some kind of delta and make it 80% when they return to 100%, just make the behavior highly predictable for the end user and return it directly to 100%.

[TheTechnician27]

Hmm, now that I think about it, volume sliders in the settings should override up/down hotkeys iff the sliders are used after the user has changed the volume up or down via hotkeys. I did some testing, and that behavior is what felt the most natural and intuitive to me. Having a FF slider (big misnomer; it's just != 1.0f speed) convolutes this a bit, but I'll come up with and present something.

[kamfretoz]

Everything listed in the suggested testing step seems to be working properly.

[JordanTheToaster]

My ears burn...

[TheTechnician27]

Latest pushes after Ziemas' review only exist to split this into two commits. No functionality has been changed.