This lock causes a deadlock when freeing the JACK client while a
process callback is pending:
deactivate_jack -> locks mutex
JACK thread -> calls jack_process_callback
jack_process_callback -> blocks on mutex
jack_client_close -> joins JACK thread
(deadlock as the process callback never returns)
Instead, just don't lock the mutex. This is only mutexing on
creation/destruction of the JACK client. This is not necessary: the
process callback will only run after jack_activate (which is right
before the mutex is released in jack_init()), and will stop running
by the time jack_client_close returns. We don't actually need to
unregister any ports, so just call jack_client_close first thing in
deactivate_jack, which will guarantee the process callback has
completed before returning.
In fact, jack_process_callback isn't allowed to lock any mutexes or
allocate any memory at all, so this plug-in is still broken in this way
as obs_source_output_audio does that. This can cause audio xruns, as
realtime guarantees are violated. This is something that should be
fixed in the future, but at least it's not a deadlock.
The previous calculation was completely broken, returning offset
timestamps in the best case, and complete insanity in the worst case
(e.g. if an xrun occurs or JACK otherwise has a glitch).
This reverts commit 4e5f20dcbe.
This originally was added because of a faulty assumption that it would
change defaults, but defaults were apparently broken from 26.0.2 -> 26.1
because primaryScreen->size() changed its behavior, so the original code
technically fixed the original behavior.
The new scaling behavior affects defaults, so only apply it to new
installs of 26.2 or greater, while maintaining the previous behavior if
the user is upgrading from an older version.
Without this change, new profiles created on systems using a fractional
scaling factor (e.g., 125%, 150%, 175%) will get an incorrect (X, Y)
pair for the new canvas size. For a display with 125% scaling, OBS would
set (1536, 864) instead of (1920, 1080). With this change, it will set
(1920, 1080).
Request / response latency dominates the download time of small
files and patches, especially the locale files. Increasing this to
4 doesn't consume many more resources and basically doubles the
download speed, especially on higher latency connections.
Unfortunately WinHTTP doesn't support multiplexing with HTTP2, but there
is still some minor benefit to enabling it. Windows 10 21H1 will enable
TLS 1.3 client support in Schannel, so let's get ready for it.
jp9000
Colin EdwardsandGitHub
Ryan Foster
Adrián PardiniandJim
SCG82andJim
Hector MartinandJim
Avital Yachinandjp9000
Richard Stanway
Warchamp7andJim
Clayton GroeneveldandJim
Andrew WoodwardandJim
Michael R. CrusoeandJim
pkubajandJim
Biswapriyo NathandJim
gxalphaandJim
Justin BullandJim
PatTheMavandJim
Gol-D-AceandGitHub
RodneyandGitHub
pkv
Theodore DuboisandJim