frontend: Avoid using Monitor Only in the UI

[Warchamp7]

Description

Removes Monitor Only from the list of monitoring options in the Advanced Audio Properties window and avoids setting it when changing mute/monitor settings via the UI.

Shows a warning icon when a source is unmuted but set to Monitor Only.

Note

This PR intentionally does not remove Monitor Only internally or change handling of it. This will be done in a later breaking release.

Motivation and Context

The Audio Mixer refactor in #12735 added a toggle button for controlling audio monitoring. This behaved as a pseudo tri state, setting monitoring to either OBS_MONITORING_TYPE_MONITOR_ONLY or OBS_MONITORING_TYPE_MONITOR_AND_OUTPUT depending on the muted state of the source.

This led to some state desync issues when controlling mute state via plugins or websocket, as the UI was the only thing aware of this handling. #13378 adjusted the behaviour to be handled within libobs itself so that audio monitoring was entirely dependent on the state of the sources monitoring setting itself.

However this NOW leads to the UI exposing a previously confusing state:
A source set to monitor only will never output to stream/recordings, regardless of the muted state of that source. In past versions, the UI would reflect the muted/unmuted state. We have essentially "fixed" this so the mute icon reflects whether the source is going to output but it is now confusing to use a hotkey or websockets to toggle mute state, and have nothing happen in the mixer.

With the changes to the UI and monitoring behaviour itself, the monitoring enum no longer makes sense. It will be deprecated/removed in a future version and replaced with a monitoring on/off boolean.

In the interim, this PR avoids setting Monitor Only via the UI as it is now an obsolete setting and will use the existing warning icon when an unmuted source is set to monitor only.

Any interaction via the UI will resolve this.

How Has This Been Tested?

Toggled the mute state of sources via websockets. Ensured that untouched sources did not have their state changed and that anything set to Monitor Only remained as such in older versions.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

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.

[notr1ch]

Reusing the unassigned audio track warning for this feels a bit weird, won't the user will get a dialog about unassigned sources if they click it? If it's becoming a generic "something is wrong with your audio" icon then the variable names and behavior should change too.

[PatTheMav]

With all the changes made so far, why is this even necessary still?

Because the code to me reads like "if monitoring is already enabled, enable monitoring", or is this a hidden attempt at coercing the "monitoring only" value into the "monitoring and output" value?

If it's the latter, that should rather be done explicitly in the code that is importing the now incompatible value and not implicitly in an unrelated code path.

[Warchamp7]

It's to allow the UI to be able to 'resolve' this state when set via a plugin or websockets. The UI itself can never set a source to MONITOR_ONLY now. Forcefully overriding the value on source load would be a breaking change, and I have that lined up for a 33 PR.

I adjusted the code here to be clearer.

[PatTheMav]

Maybe worth refactoring the whole function to:

void VolumeControl::handleMonitorButton(bool enableMonitoring)
{
    obs_monitoring_type newType = (enableMonitoring) ? OBS_MONITORING_TYPE_MONITOR_AND_OUTPUT : OBS_MONITORING_TYPE_NONE;

    setMonitoring(newType);
}

Making this branchless doesn't negatively impact readability in my view, though at least in isolation with optimisations turned on most compilers will convert this into the exact same code (and even optimise the branch out automatically).

[Warchamp7]

Done.

[Warchamp7]

Reusing the unassigned audio track warning for this feels a bit weird, won't the user will get a dialog about unassigned sources if they click it?

No, it doesn't trigger the warning dialog. Just applies the icon.

If it's becoming a generic "something is wrong with your audio" icon then the variable names and behavior should change too.

Done.