Hello Apple engineers and developers, My name is Fumikazu Kondo. I am an independent developer in Japan working on transcription applications, including KF Transcription Mixer. I want to capture two separately connected Bluetooth microphones on a Mac for meeting and conversation transcription. I would appreciate an Apple engineer's response about the supported behavior and a reliable solution. Problem Each microphone works when captured individually. When both are opened, the second input delivers only zeros, even though Core Audio starts successfully and macOS reports two SCO connections. The failure also reproduces with direct native Core Audio capture before any application audio processing. Environment MacBook Pro, Apple M5, model identifier Mac17,2 macOS 27.2; sw_vers reports build 26B123 Xcode 27.1 (27A9275), macOS 27.0 SDK Built-in Bluetooth controller: BCM_4388C2, firmware 24.2.241.1936 Microphones: Beats Pill (firmware 2C336) and SANWA SUPPLY MM-BTCL1 (firmware 1.0.0), both directly connected to the Mac Both input devices expose 16,000 Hz, mono. Bluetooth logs show HFP/mSBC. Microphone Mode: Standard; preferred and active values both read back as 0 Reproduction Connect both microphones to the Mac. Confirm each delivers real audio in a separate, fresh capture process. In Audio MIDI Setup, create an Aggregate Device with the two microphone input devices, one channel each. Use 16 kHz, one clock source, and drift correction for the other device. Start capture of the two channels. Use a controlled speech fixture played through the Mac's built-in speakers so that both microphones receive sound. Observe that one channel has audio and the other is entirely silent. I also reproduced the problem using AudioDeviceCreateIOProcID / AudioDeviceStart directly on the physical input devices, without an aggregate or application processing. Reversing their opening order changed which microphone remained silent: the later-opened device delivered zeros. Measured results Physical Mac XCTest runs on October 30, 2026: MM-BTCL1 alone: 203,520 captured frames; 232 nonzero observation windows; passed. Beats Pill alone: 203,520 captured frames; 233 nonzero observation windows; passed. Two-input aggregate: 202,240 frames; nonzero windows [240, 0]; simultaneous windows 0; application audio error 0. Separate native shared-clock experiment: an aggregate containing both microphone inputs plus the built-in speaker, driven by one full-duplex IOProc. 1,152 input callbacks and 1,152 output buffers; nonzero callback counts [1100, 0]; simultaneous windows 0; invalid samples 0. The last experiment rules out simply lacking a running output clock in the input-only capture path, but it did not fix the issue. Relevant system log messages include: Number of SCO Connections: 2. A2DP Streaming State: 0. Input Decode: Requested 640 bytes, but only read 0 bytes instead. Decoded a total of 0 bytesThe decode message repeats during the silent input. Successful voice-audio connection events appear for both devices. Device identifiers and unrelated logs are omitted here. Already tested Both microphones power-cycled and individually reconnected Mac restarted; issue reproduced afterward Standard microphone mode verified by readback Both microphones individually verified with the same controlled stimulus Reversed native device opening order Persistent and private aggregates; different clock choices and drift correction Direct physical-device IOProc capture Full-duplex shared-clock capture with the built-in speaker Built-in speaker selected as system output, with Bluetooth output streaming stopped during measurement Core Audio and Bluetooth services restarted; issue persisted Software Update reports no new software available I have not established whether the cause is in the OS, driver, controller, or device firmware. I am not claiming a universal Bluetooth specification limitation. Questions for Apple Is simultaneous capture from two directly connected HFP/mSBC microphones supported on this Mac/macOS configuration through Core Audio? If there is a limitation, could you provide the relevant documentation and clarify its scope? If supported, which public API or configuration should be used to keep both input streams delivering audio? Is there a known issue or supported workaround for the all-zero second stream? Which targeted Bluetooth/HCI logs or minimal reproduction details would Apple need to investigate? I can provide a focused reproduction and redacted measurements through an appropriate private channel if needed. This is blocking reliable two-microphone transcription. Please respond with the expected behavior, next diagnostic steps, or the appropriate Apple engineering support route. Thank you for your help. Update: also reproduced with two Beats Pill speakers On October 30, 2026, I replaced the MM-BTCL1 with a second Beats Pill. Both Beats Pill speakers report firmware 2C336 and are independently connected to this Mac. Microphone Mode remains Standard (0). Fresh individual controls after previous SCO connections fully disconnected: both work (235 and 236 nonzero observation windows). Application-created private aggregate, device order A/B: nonzero windows [233, 0]. Reversed participant order: [0, 240]. Direct physical-device IOProc test, opening A before B: callback counts [404, 402], but nonzero callback counts [403, 0]. No simultaneous audio windows. After releasing both and restarting B alone, B delivers audio (381 nonzero callbacks). Opening A while B continues then yields nonzero counts [0, 404]: the later-opened device is again silent. System logs again report two SCO connections and repeated zero-byte input decode messages. Thus the same failure also reproduces with two same-model, same-firmware Apple/Beats devices. Please include this configuration when assessing support status, a possible known issue, and recommended next steps. Additional comparison reported by the user: the MacBook built-in microphone and one Beats Pill can both be heard when used together. This is a user-observed working configuration, separate from the automated tests above. It further narrows the problem to the configuration with two simultaneous Bluetooth microphone inputs.