Creative Zen Hybrid Pro doesn't work

[tlvince]

I'm working through an issue with Bluetooth LE Audio with a new headset (Creative Zen Hybrid Pro). With help from @pv, we believe BAP's triggering a bug in the adapter's firmware (MediaTek MT7922) - in short, the headset connection establishes, but the adapter hits a bug and restarts. See No sink created for Creative Zen Hybrid Pro LE Audio LC3 device and MediaTek MT7922 controller crashes after LE Setup Isochronous Data Path for details.

Debugging this has also triggered a few crashes in BlueZ. Here're some logs for a few different scenarios:

1. BlueZ crashed from boot - maybe a cache issue - went away after clearing /var/lib/bluetooth/*
2. After connecting the headset and starting pipewire

Some related logs if they're of use:

• Not a crash, but example of the linked issue with the adapter cycling from bluez and pipewire
• dmesg.log
• btsnoop-log.txt showing the adapter coredump

Versions:

• bluez: 58e6ef54e672798e2621cae87356c66de14d011f with these flags (including --enable-asan)
• Linux 6.6.1
• pipewire 1030d4ccbb3ac43c50a01547345916cac3a4706f

❯ cat /etc/bluetooth/main.conf 
[General]
ControllerMode=le
Experimental=true
KernelExperimental=6fbaf188-05e0-496a-9885-d6ddfdb4e03e

[Policy]
AutoEnable=true

[Vudentz]

@tlvince seems to be working correctly with the patch above, but pipewire also needs to adopt the same logic for calculating the resulting SDU in case it wants to multiplex l+r over the same CIS.

@pv what is the plan for pipewire to adopt ChannelLocation and multiplexing in general?

[pv]

Pipewire already supports multiplexing channels in same CIS.

I have this device and looked at it a while ago, and it seems like it has firmware bugs that cause problems:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3666#note_2183197

Also, the device has Supported_Max_Codec_Frames_Per_SDU == 1 in its PAC, even though it can multiplex two channels in a CIS. The BAP spec is unclear on whether this value is frames per channel or not, but IIUC it should be 2. Because of this, PipeWire currently configures a mono stream. In principle we could (and maybe should) instead ignore this value and just use the channel count bitmasks.

[Vudentz]

Pipewire already supports multiplexing channels in same CIS.

I have this device and looked at it a while ago, and it seems like it has firmware bugs that cause problems: gitlab.freedesktop.org/pipewire/pipewire/-/issues/3666#note_2183197

Also, the device has Supported_Max_Codec_Frames_Per_SDU == 1 in its PAC, even though it can multiplex two channels in a CIS. The BAP spec is unclear on whether this value is frames per channel or not, but IIUC it should be 2. Because of this, PipeWire currently configures a mono stream. In principle we could (and maybe should) instead ignore this value and just use the channel count bitmasks.

I see, yeah Id go with ChannelLocation bitmask and also try setting it when configuring, not sure if pw does that already. The way PAC records has its capabilities is not very clear about the audio configuration it supports, so it is a little bit of a hit or miss right now, in theory the device could have multiple records of LC3 to try to narrow down its capabilities. Btw, is the Supported_Max_Codec_Frames_Per_SDU = 1 perhaps only for the source? Need to record the HCI trace to see unde what ASE does that comes from.

[pv]

I see, yeah Id go with ChannelLocation bitmask and also try setting it when configuring, not sure if pw does that already. The way PAC records has its capabilities is not very clear about the audio configuration it supports, so it is a little bit of a hit or miss right now, in theory the device could have multiple records of LC3 to try to narrow down its capabilities.

We pick the channels based on PACS Locations (and PAC Supported_Audio_Channel_Counts & Supported_Max_Codec_Frames_Per_SDU), and set the channel allocation in the LTV config. The new ChannelAllocation DBus argument in BlueZ is not supported yet in Pipewire, but it's only pending on me finding time to work on it.

Btw, is the Supported_Max_Codec_Frames_Per_SDU = 1 perhaps only for the source? Need to record the HCI trace to see unde what ASE does that comes from.

IIRC, it's the Sink PAC that has Supported_Max_Codec_Frames_Per_SDU=1 and Supported_Audio_Channel_Counts=0x3, to get it to work I needed to skip our Supported_Max_Codec_Frames_Per_SDU value check.

[pv]

The latest Creative Zen Hybrid Pro firmware update (1.2.231215.1500, 06-01-2024) seems to break connecting in LE mode altogether for me (also with bluetoothctl not pipewire), the device disconnects while ASE configuration is in progress.