[Stasyanych]

On macOS, activating the microphone of a Bluetooth headset (AirPods) switches the device from A2DP (48 kHz) to HFP (24 kHz in the log). The WebRTC macOS ADM rejected the format change in HandleStreamFormatChange when streamFormat.mChannelsPerFrame != _recChannels. That check is wrong for playout: _recChannels is the capture channel count (1), while the output has 2 channels. As a result, _outStreamFormat and the render converter stayed at 48 kHz while the device was already running at 24 kHz. Audio played back slowed down; reopening the sound settings or reinitializing playout re-read the actual device format and fixed it only temporarily.

On the capture side, _captureConverter was recreated directly in the CoreAudio listener thread while the capture worker was using it. That is a race: capture could break or be corrupted on a format change, and the sample count could be computed incorrectly if _inStreamFormat had already been updated but the data arrived in the new format.

What the patch does:

• playout: removed the incorrect channel check based on _recChannels; the new output format is accepted, _outStreamFormat is updated, mono fallback is applied when needed, and the render converter and device buffer parameters are rebuilt via SetDesiredPlayoutFormat();
• capture: converter recreation is deferred to the capture worker. The listener only stores the pending format and sets a flag; the worker applies it, drops frames during the transition, and disposes the old converter after creating the new one. This removes the listener/worker race;
• fixed the sample count calculation in the input IOProc: use the actual buffer size (interleaved Float32) instead of potentially stale _inStreamFormat;
• added logging for applied formats and capture/playout changes.

As a result, the application-level workaround that reinitialized audio devices after connection is no longer needed.

Tested on macOS:

1. AirPods selected as the playback device before the call starts.
2. AirPods connected/selected during a call, with audio initially going through the built-in speakers. In both cases audio plays correctly after the HFP switch, with no slowdown and no silence.

Affected files:

• modules/audio_device/mac/audio_device_mac.cc
• modules/audio_device/mac/audio_device_mac.h