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).
For 'pulse_output_capture', calls are added when devices are either
changed, started or removed.
The calls trigger a check against the monitoring device.
Signed-off-by: pkv <pkv@obsproject.com>
For 'coreaudio_output_capture', calls are added when devices are either
changed, started or removed.
The calls trigger a check against the monitoring device.
Signed-off-by: pkv <pkv@obsproject.com>
For 'wasapi output capture', calls are added when devices are either
changed, started or removed.
The calls trigger checks against the monitoring device.
Signed-off-by: pkv <pkv@obsproject.com>
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>
Improves app shutdown in a few ways, including separating out different
pieces of the OBSBasic close handler into their own functions.
Removes the crash handler sentinel earlier when the main window is closed,
preventing unclean shutdown warnings when a plugin causes issues. While not
ideal, the dialog is not useful when we cannot specify which plugin caused the
problem.
Increases shutdown priority of the main application so that when OBS interrupts
the session ending, CEF is not closed at the same time. This fixes a crash.
Additional safeguards and event handling to try to ensure a smoother shutdown.
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>
Per the Apple documentation, when 0 is returned from
IOSurfaceGetPixelFormat, the IOSurface is invalid. Prior to [1] however,
any invalid surfaces were (likely accidentally) treated as 32BGRA.
And as it turns out, any IOSurface received from Syphon does not have
the pixel format set, thus returning 0. Because the pixel format happens
to always be 32BGRA, this was never caught. [1] then slightly refactored
the code, fixing the bug not realizing it ever existed. This lead to
Syphon no longer working.
Treating 0 as 32BGRA appears to be the only way to fix this situation
for now and restore prior behavior. Ideally in the future Syphon
provides valid IOSurfaces. An upstream fix to Syphon-Framework is
already submitted, however even if merged, servers would need to update
to that fixed version before things work again. Therefore, this
workaround is needed on the OBS side.
However, the plan for now is for the Metal renderer to not get this
relaxation. It never had it (so Syphon never worked there, making this
not a regression) and it's marked as experimental. Hopefully, by the
time it's stable and/or default, Syphon will be fixed and servers have
been updated.
[1]: 53ad05db9f
By explicitly setting the OAuth dialog as the parent of the CEF widget,
it will automatically by cleaned up as soon as the dialog is closed
itself.
This also detaches the destruction of the widget from the browser
cleanup code.
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>
This removes the need to provide an undocumented launch argument to
enable custom RTMP service configurations to use multitrack encoding
and also provide a custom configuration.
The default of 2500 kbps was chosen 10 years ago and times have changed.
Logs and forums posts show that many users of OBS for recording don't
change their bitrate and end up with a 2.5 mbps recording which looks
terrible.
Now that service bitrate enforcement exists, this will be automatically
capped to the maximum bitrate for streaming services, so the only time
this should result in a problem is if the user's upload speed is the
limiting factor, hopefully rarer these days with increasing internet
speeds.
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.