macOS: OBS hangs indefinitely (beachball) starting an Audio Input Capture source when the device isn't ready — no timeout on AudioOutputUnitStart

Operating System Info

macOS 26

Other OS

No response

OBS Studio Version

32.2.2

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/KLSTSgZ3WWhlkj9D

OBS Studio Crash Log URL

No response

Expected Behavior

OBS should not be able to hang the main thread indefinitely just because an audio capture source's underlying device can't complete its start handshake at that moment. It should time out, log an error, and either skip or retry the source, rather than freezing the whole application permanently.

Current Behavior

OBS becomes completely unresponsive (spinning beachball) and never recovers — it has to be force-quit, and no crash report is ever generated. This happens when a USB audio capture device backing an Audio Input Capture source is present/enumerated on the bus but not able to actually start its I/O stream (in my case, a Hollyland Lark M2 wireless mic receiver whose RF link to its transmitter has dropped — macOS shows a system notification that the wireless mic is unavailable — while the receiver itself stays connected via USB). Most reliably reproduced when this state exists while OBS is loading a scene collection at launch.

I captured a live Activity Monitor "Sample Process" trace of OBS while frozen in this exact state. 100% of the sampled duration (2022/2022 1ms samples) shows the main thread stuck in:

DispatchQueue_1: com.apple.main-thread (serial) obs_load_sources (in libobs) obs_load_source_type (in libobs) obs_source_create_internal (in libobs) [mac-capture plugin, 3 stripped frames] AudioOutputUnitStart (in AudioToolboxCore) [CoreAudio, 3 stripped frames] AudioDeviceStart_mac_imp (in CoreAudio) HAL_HardwarePlugIn_DeviceStart(...) (in CoreAudio) HALC_ProxyIOContext::StartIOProc(...) (in CoreAudio) HALC_ProxyIOContext::_StartIO(...) (in CoreAudio) HALB_IOThread::StartAndWaitForState(unsigned int) (in CoreAudio) HALB_IOThread::_WaitForState(unsigned int) (in CoreAudio) HALB_Guard::WaitFor(unsigned long long) (in CoreAudio) _pthread_cond_wait (in libsystem_pthread.dylib) _pthread_mutex_firstfit_lock_slow (in libsystem_pthread.dylib) _pthread_mutex_firstfit_lock_wait (in libsystem_pthread.dylib) __psynch_mutexwait (in libsystem_kernel.dylib)

The associated com.apple.audio.IOThread.client thread is idle in mach_msg waiting on the HAL server (coreaudiod) — coreaudiod never signals back that the device finished starting, and OBS's main thread waits on that signal with no timeout, forever.

This looks like it may be the same underlying issue reported (without a stack trace) in #12044 ("Preview Freezes & System Audio Stops (no crash, M4 Max or M-series)"), which was closed as a support request for lack of evidence. Hopefully this trace gives enough to reopen/investigate. Happy to attach the full Sample Process .txt file if useful.

Steps to Reproduce

1. Add an Audio Input Capture source pointed at a class-compliant USB wireless-mic receiver (e.g. Hollyland Lark M2) to a scene, and save that scene collection.
2. Let the receiver's wireless link to its transmitter drop while the receiver itself stays plugged directly into a USB port and enumerated (macOS shows a "wireless mic unavailable"-style notification in this state).
3. Launch OBS (or switch to/reload the scene collection containing that source) while the device is in this "present on the bus but not answering" state.
4. OBS beachballs immediately and never recovers; it has to be force-quit.

Anything else we should know?

Hardware: Apple Silicon Mac mini, model identifier Mac16,10 (arm64). Audio device: Hollyland Lark M2 Combo wireless mic system, receiver plugged directly into a USB-C port on the Mac mini (no hub/dock in between), receiver firmware up to date. I'll attach the full Sample Process .txt and an OBS log URL (via Help > Log Files > Upload Current Log File) as a follow-up comment.