Re: MT7925 (0e8d:0717): HFP microphone unusable — firmware delivers zero-filled (e)SCO frames on sentinel handle 0x0E00

[Mo <dabiggmoe@gmail.com>]

Hi,

Independent reproduction of this report on different hardware, a different
headset and newer firmware.

Hardware:  Framework Desktop (AMD Ryzen AI Max 300), BIOS 03.06
            MediaTek MT7925 (RZ717), BT on USB 0e8d:0717
Firmware:  BT_RAM_CODE_MT7925_1_1_hdr.bin build 20260813113236
            (linux-firmware 20261019, newer than the builds tested above)
Kernel:    7.3.0-5-cachyos
Userspace: BlueZ 5.87, PipeWire 1.6.11, WirePlumber 0.5.19
Headset:   Sony WH-1000XM4 (HFP, native backend)

Symptoms match: A2DP is fine; in HFP the microphone stops delivering audio
while the SCO link stays up. The kernel logs the same signatures:

   Bluetooth: hci0: corrupted SCO packet
   Bluetooth: hci0: SCO packet for unknown connection handle 3584

(32 "corrupted SCO packet" and 18 "handle 3584" lines in the current boot.)

Observations that may help:

- Codec-independent here. It fails with mSBC (Transparent) and also after
   pinning CVSD (headset-head-unit-cvsd): the CVSD session failed about two
   minutes after a fresh reconnect, with "corrupted SCO packet" x3 
followed by
   "handle 3584" at the moment the capture went silent. So removing 
mSBC, the
   workaround that helps MT7921 users in bluez#2545, does not avoid it 
on this
   MT7925.

- Two failure shapes seen at capture level (pw-record on the BT source):
   1. Pure zeros (max amplitude 0.000000) for roughly 8-22 s after a
      "corrupted SCO packet", then audio recovered without any reconnect.
   2. A persistent state where speech arrives about 35 dB too low (peaks
      around -45 dBFS vs about -18 dBFS when healthy). No userspace errors
      are logged; a profile switch (mSBC -> CVSD) does not clear it, only a
      full ACL disconnect/connect does.

- Not the headset or userspace: a USB headset on the same machine and the
   same PipeWire/Steam setup works, and the WH-1000XM4 mic is fine on other
   hosts.

I can run a btmon capture of a failing session, test patches against
bluetooth-next or mainline, or try other firmware builds if that helps.

Is anyone from MediaTek looking at the 0x0E00 SCO frames?

Thanks,
Mo