### System details

Omarchy 4.0.4-1 Linux kernel 7.1.9-arch1-2 PipeWire 1.6.8 BlueZ 5.87 bluez-utils 5.87 Bluetooth adapter: Realtek Hyprland  Affected Bluetooth devices: - OnePlus Bullets Wireless Z2 - JBL Tune 770NC  Same microphone problem also reproduced previously on Linux Mint Cinnamon.

### What's wrong?

Bluetooth microphone input does not work correctly with multiple Bluetooth headsets/headphones.

I tested:

* OnePlus Bullets Wireless Z2
* JBL Tune 770NC

With both devices:

* Bluetooth pairing and connection work.
* A2DP playback works normally.
* HFP/HSP microphone profiles are available.
* The Bluetooth microphone source is exposed by PipeWire.
* `pw-record` can successfully record from the source.
* HFP/eSCO transport can be established.
* However, the resulting microphone recording contains effectively complete digital silence.

For example, recording directly through PipeWire and analyzing the WAV with FFmpeg consistently gives:

```text
mean_volume: -91.0 dB
max_volume:  -91.0 dB
```

I tested both HFP modes:

```text
HFP CVSD  -> microphone source available -> silence
HFP mSBC  -> microphone source available -> silence
```

I also bypassed applications such as Chrome/Discord and tested directly with `pw-record` and `pw-cat`, so this does not appear to be an application-specific microphone permission or routing issue.

During troubleshooting, `btmon` showed successful HFP/eSCO connection establishment, for example:

```text
Synchronous Connect Complete
Status: Success
Link type: eSCO
Air mode: CVSD
```

However, WirePlumber repeatedly reports:

```text
spa.bluez5: Failure in Bluetooth audio transport
/org/bluez/hci0/dev_<redacted>/sep2/fd0
```

I also observed PipeWire Bluetooth nodes transitioning into an error state.

I tried changing the WirePlumber Bluetooth auto-connect configuration to include HFP/HSP:

```text
bluez5.auto-connect = [
    hfp_hf
    hsp_hs
    a2dp_sink
    a2dp_source
]
```

and restarted:

```text
systemctl --user restart wireplumber pipewire pipewire-pulse
```

This did not resolve the issue.

I also confirmed:

```text
bluetooth.autoswitch-to-headset-profile = true
```

Manual HFP profile selection still produces silent recordings.

### Important cross-platform observation

The same microphone hardware works normally on:

* Windows 10
* Windows 11
* Android

The same problem also occurred previously on **Linux Mint Cinnamon** with both Bluetooth devices.

Therefore, this is not limited to a single Bluetooth device and does not appear to be specific to one particular Linux desktop application.

I am not sure which layer is failing, but the current evidence points somewhere in the Linux Bluetooth HFP audio path, potentially involving BlueZ, PipeWire `spa.bluez5`, WirePlumber, the Bluetooth adapter/kernel, or HFP compatibility.

### Minimal reproduction

1. Connect the Bluetooth headset.
2. Switch to HFP:

```bash
pactl set-card-profile bluez_card.<redacted> headset-head-unit-cvsd
```

3. Record directly:

```bash
pw-record --target bluez_input.<redacted> /tmp/bt-test.wav
```

4. Analyze:

```bash
ffmpeg -i /tmp/bt-test.wav -af volumedetect -f null -
```

Observed:

```text
mean_volume: -91.0 dB
max_volume: -91.0 dB
```

### Request

I would like help identifying where the microphone audio is being lost.

In particular, what would be the best diagnostic to determine whether HFP audio packets are actually reaching BlueZ and PipeWire, and whether `spa.bluez5` is failing to decode/forward them into PCM?

I can provide additional `btmon`, `bluetoothd`, kernel, PipeWire, and WirePlumber debug logs if needed.