Bug: "eqMac Export" sometimes crashes while recording on macOS Tahoe 26.2

[kaeru-shigure]

Disclaimer:
Please go through existing issues to avoid creating duplicates. If you found a similar issue please post a comment there. If you are uncertain your issue is related to others then create the issue. Obvious ignorance of this rule might get you blocked from posting new issues. Please tick the box below to show that you have followed the guideline.

• I have checked for a similar issue and sure it hasn't been reported before.

In many cases first recommendation is to update to latest version available even if it's still in beta, especially if version you are on is older than 6 months. Please tick the box below to show that you already did this and issue is still present.

• I have enabled 'Beta'/'Beta Program' in eqMac settings and updated to latest version available at the time this issue is created.

Describe the bug

On macOS Tahoe 26.2, if you start recording “eqMac Export” in some app while nothing is playing, and then start playback from any source while the recording is active, the eqMac driver crashes.

Steps to Reproduce

Steps to reproduce the behaviour (feel free to change the placeholder as you need):

1. Ensure nothing is playing.
2. In an app (e.g., Audacity), start recording from “eqMac Export”.
3. Start playback from a source (e.g., Chrome).
4. After the app you tried to play audio with becomes unresponsive for a few seconds, the driver crashes.

Depending on the playback software, it may sometimes work correctly, but the issue generally reproduces with the steps above.

Expected behaviour

Recording should work normally without issues. This worked correctly on macOS Sequoia.

Setup information:

• Audio device used for playback: Internal Speakers
• Audio transmission interface: Internal
• macOS Version: Tahoe 26.2
• eqMac Version: 1.8.12
• eqMac Driver Version: 2.6.0

Screenshots or Console.app logs

(I also tried reinstalling the driver and restarting the system several times, but it did not improve the issue.)

After repeating the steps several times, the system may freeze.
The following may be an exception that occurs at that time (it might not be directly related), but I have observed the error below.
For security reasons I can only provide fragments, but please use this as a reference.

com.apple.audio.Core-Audio-Driver-Service.helper - EXC_BREAKPOINT (SIGTRAP)

0   eqMac                         	       0x1008d8c88 Device.doIO(clientId:operationID:sample:cycleInfo:frameSize:) + 372
1   eqMac                         	       0x1008dfc50 specialized DoIOOperation(inDriver:inDeviceObjectID:inStreamObjectID:inClientID:inOperationID:inIOBufferFrameSize:inIOCycleInfo:ioMainBuffer:ioSecondaryBuffer:) + 244
2   com.apple.audio.Core-Audio-Driver-Service.helper	       0x10080e17c std::__1::__function::__func<AMCP::Portal::IPC::IO_Receiver::start_message_thread()::$_0, std::__1::allocator<AMCP::Portal::IPC::IO_Receiver::start_message_thread()::$_0>, void (caulk::ipc::mapped_memory&)>::operator()(caulk::ipc::mapped_memory&) + 996
3   caulk                         	       0x1929317b8 caulk::ipc::synchronous_messenger::semaphore_receiver::message_loop(caulk::ipc::synchronous_messenger::semaphore_receiver&) + 240
4   caulk                         	       0x1929314ac void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, caulk::ipc::synchronous_messenger::semaphore_receiver::start(double, caulk::thread::attributes const&, caulk::mach::os_workgroup_managed)::$_0, std::__1::tuple<>>>(void*) + 276
5   libsystem_pthread.dylib       	       0x186301c08 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x1862fcba8 thread_start + 8

[ragauskl]

We can replicate this which is good, a fix may be released in future updates but at the moment I can't say when as there is a list of items higher on the priority list

[kaeru-shigure]

Thanks for checking!
Got it. This is an important issue for me, so I’m hoping it’ll be resolved at some point.

[m13v]

this crash pattern is consistent with a race condition in the virtual audio driver's IO callback. when recording starts on a silent bus and then playback begins, the driver's DoIO function gets called for the first time while the recording client already holds a reference to the device's IO state. the EXC_BREAKPOINT in Device.doIO suggests a forced unwrap or assertion failure on a nil buffer that hasn't been initialized yet.

we've seen similar issues with CoreAudio driver services on Tahoe where the IO thread scheduling changed. Tahoe introduced stricter deadlines for IOAC (IO Audio Context) threads, and drivers that previously got away with lazy initialization now hit assertion failures because the audio system calls doIO before setup completes.

the fix typically involves pre-allocating all ring buffers and IO state when the device is created (not on first IO call), and guarding the doIO path with a check that the playback stream is actually started before attempting to read from it. returning silence frames instead of crashing is the safe fallback.

the system freeze after repeated reproduction is likely the audio server process (coreaudiod) accumulating zombie connections from crashed driver instances. after enough crashes, coreaudiod runs out of mach port space and hangs, which cascades to every app that uses audio.

[m13v]

for reference, our ScreenCaptureKit service that handles the audio/video capture lifecycle with proper state initialization before IO begins (relevant to the pre-allocation pattern): https://github.com/m13v/macos-session-replay/blob/main/Sources/SessionReplay/ScreenCaptureService.swift