The default device retrieved was the one used for system sounds.
This fixes it by retrieving the one used to output audio.
It seems the bug has been there since the initial writing of this bit of
code (so 2017).
The monitoring deduplication was previously checking at each audio tick
the whole audio tree for Audio Output Capture (AOC) devices used for
monitoring. The profiling did not show any big impact on the audio
callback. But due to reports of a significant slowdown for scenes with
numerous audio sources, we have moved the check on AOC from the audio
thread to the UI thread.
So we implemented obs_source_audio_output_capture_device_changed which
is triggered whenever:
- a monitoring device is changed in Settings > Audio,
- an Audio Output Capture source changes its device or on startup.
This function compares the AOC device with the monitoring device in UI
thread. If they are identical, a signal is sent to the audio thread to
add an audio task updating the AOC duplicating source pointer at the end
of an audio tick.
This triggers monitoring deduplication if the ptr is not NULL.
The calls in the AOC are implemented in next commits.
The rest of the logic in obs-audio.c is the same except on one count,
which is that we check against the muted state of the AOC rather than
its user_muted; with the new logic, muted works better.
Signed-off-by: pkv <pkv@obsproject.com>
This adds the devices_match function to null monitor to fix linking
issues on linux when pulse audio is disabled.
Fixes#12810
Signed-off-by: pkv <pkv@obsproject.com>
This adds comparison to default devices to the monitoring deduplication.
When a user picks a default device, the device_id setting is 'default',
which prevents any comparison.
The comparison is done by leveraging the libobs/audio-monitoring
devices_match function.
For macOS, some special care is taken because the devices list differ
for 'Desktop Audio' and 'monitoring' since coreaudio sdk has no pure
audio capture; so 'default' in the two lists do not match in general.
One then retrieves the device_id for the default desktop audio for macOS
through get_desktop_default_id function.
Signed-off-by: pkv <pkv@obsproject.com>
When the 'Audio Output Capture' source (usually Desktop Audio) has its
fader at minimum, we should disable the deduplication logic.
This is done by checking against the obs_source volume member.
Signed-off-by: pkv <pkv@obsproject.com>
Monitoring deduplication must be applied only to tracks for which the
monitored source and the 'Audio Output Capture' source are both enabled.
This adds such checks.
Signed-off-by: pkv <pkv@obsproject.com>
The commit adds a log line to inform the user that deduplication is
being applied. The info is displayed whenever deduplication first
occurs.
Signed-off-by: pkv <pkv@obsproject.com>
When an 'Audio Capture Source' device is also used for monitoring, the
deduplication logic is applied: all monitored sources are silenced.
But this should not silence the 'Audio Capture Source' if for some
reason, it is being monitored (the user will get echoes, but hey, it's
their choice). So we exclude the 'Audio Capture Source' from the
silenced sources.
Signed-off-by: pkv <pkv@obsproject.com>
The previous attempt to clarify an out of memory exception/crash
resulted in the compiler optimizing os_breakpoint() and os_oom() into
the same result, which meant that crash stacks in the wild were still
not specific enough to be helpful. Forcefully differentiating the
functions in Release configuration by having os_breakpoint() only call
__debugbreak() and having os_oom() call RaiseException() should give us
clearer crash stacks.
Amends 94a736f179.
It's important to differentiate whether a plugin fails to open (dl_open
returning NULL, being compiled for a newer libobs, etc) or whether it
opened correctly, but failed to initialize (returned NULL during
obs_module_load()).
With that, we can also create disabled modules for modules that fail to
open, which in the future should enable better user communication in the
UI (besides the module_load_failure_info).
This code is returned if os_dlopen returns NULL. This can happen for
multiple reasons, not just because the file can't be found. Since [1]
other causes are getting more common, but this could also happen before.
[1]: 62429135ba
Partial revert of a0eae6f33c.
Partial revert of 23c3ad4d02.
Partial revert of 97b34ebb76.
Keep all of the get_plugin_info stuff, remove the Qt5 checks.
[1] changes this condition to obs_source_is_scene as a drive-by, however
they aren't equivalent. obs_source_is_scene checks whether the source's
is is "scene", which doesn't include groups, while OBS_SOURCE_TYPE_SCENE
does. Suddenly not including groups is quite the API break.
This now means obs_canvas_enum_scenes does also include groups, however
that is much less of an egregious API change.
[1]: 8c5858ae05
RTLD_LAZY means that symbols will only be resolved when first used,
while RTLD_NOW tries to resolve them immediately. This means that if
there are missing symbols (e.g, because a function got removed from
libobs), dlopen with RTLD_LAZY will happily open that module but we get
a runtime crash when the module tries to use that symbol, while with
RTLD_NOW we instead get a (nicer) error on dlopen.
These were likely originally used for the obs_*_get_module functions,
but no longer are. Additionally, they weren't even implemented for
anything but obs_source_info. Let's remove this before it hits stable.
Phase 1 of the plugin manager provides the the ability to toggle off/on
plugins loading when OBS starts. Additionally, it implements loading of
a manifest file for plugins that allows plugin authors to provide more
detailed information about the plugin including authors, support site,
name, description.
In order to accomplish this, this change updates libobs to provide
more detailed tracking of modules- specifically tracking both enabled
and disabled modules, alone with a module load state which indicates
why a module is not loaded. Additionally, changes were made to establish
a links between a module and any features (inputs, outputs, encoders,
and services) it provides (and thus the ability to determine why a
feature might not be enabled). Along with these changes to modules,
this commit also provides an indicator and lookup for core modules which
can not be disabled by the plugin manager.
Finally, this change provides functions to properly load and retrieve
a standardized plugin metadata file.
The autoselect functionality was meant to enable user feedback for when
data was selected, but something else actually used, for example in case
the value "Auto" was chosen, or an incompatible one.
However, it has a few problems:
1. It was not really used, the only places in OBS were the legacy Video
Capture Device on macOS and the Video Capture Device on Windows.
2. It was never even fully implemented in the UI. In fact, the
properties view *only* supports it for obs_property_list, despite the
API theoretically allowing any data/property type.
3. The core obs_data seems like the wrong place for this kind of
interaction between plugins and UI. obs_data should carry data from one
place to another, some built-in feedback mechanism for the other
direction doesn't make too much sense. If the functionality is desired,
I think this should be rearchitectured as some place of explicit data
transfer.
Let's mark it as deprecated for future removal.
On MSVC, PRAGMA_WARN_DEPRECATION already does that, but on other
compilers it still throws a warning. PRAGMA_DISABLE_DEPRECATION is for
(rare) situations where it's intentional and correct that the deprecated
API is still used, such as to make sure some other API still works
internally.
