Fix TWS battery, rfcomm crash, quality/speed selector, equalizer fetch and macOS icon

[zezic]

Sound quality mode

Prioritize sound quality vs. stable connection

New control on all three platforms, capability-probed like the rest. It's the AUDIO parameter family this repo already speaks for DSEE (e6/e7/e8), where the sub-type byte picks the feature: 0x01 is upscaling, 0x00 and 0x02 are the connection mode (plain, and the variant LDAC-capable models answer on). GET e6 sub → RET e7 sub mode, SET e8 sub mode, with mode (Sony's PriorMode) 0x00 = sound quality, 0x01 = stable connection.

GadgetBridge doesn't implement this one, so the layout comes from mos9527/SonyHeadphonesClient's libmdr, generated from the decompiled Sony MDR tables. Its Command enum matches our v2 opcodes byte-for-byte (0x12 common, 0x22 power, 0x56 EQ, 0xe6–0xe8 audio), and 0xe6 01 is already hardware-confirmed here as DSEE.

probeCapabilities() tries the LDAC sub-type then the plain one and keeps whichever replies, since SET has to go back out on the same sub-type. Two guards: 0x05 (CONNECTION_MODE_CLASSIC_AUDIO_LE_AUDIO) is never sent — its SET carries a fourth byte that also switches the device between Classic and LE Audio — and the probe only accepts a value byte of 0x00/0x01, so a misread layout leaves the feature unsupported instead of exposing a control that writes garbage.

Writing it makes the device re-negotiate A2DP, which takes the RFCOMM channel down with it, so the SET is fire-and-forget and the disconnect watcher explains the drop rather than reporting a bare failure. The macOS card shows the negotiated codec next to the toggle, which is the only way to see the setting do anything on a host without LDAC.

Was tested on my macOS machine and it let A2DP to negotiate 192kbps instead of default 144kbps which I'm very happy with (because no LDAC on Mac, you know).

Battery

Per-earbud levels on TWS

requestBattery() probed the single-battery sub-type first and returned on any reply, so earbuds never reached the dual probe and L/R stayed empty. Probe order now follows the model name, with a fallback either way.

Also: DUAL2 (0x01) for the WF-C5xx/C700N line, per-earbud charging flags, level 0 treated as docked rather than flat, case battery (0x0a), and a periodic re-poll so it stops going stale (v2 only — 0x22 is POWER_OFF on v1).

Verified on a WF-1000XM5: docking one earbud moves byte [4] and nothing else. Its replies are longer than the documented layout (8/5 bytes vs 6/4), so size checks are lower bounds; captured frames are in Constants.h.

Crash on disconnect

rfcommchannel was a non-owning __bridge pointer, never cleared when the link dropped — an in-flight poll would writeSync: to a freed channel (EXC_BAD_ACCESS). Docking an earbud was enough to trigger it. Now retained and cleared under a mutex; send() raises a recoverable error instead.

Also fixes a self-join (rfcommChannelClosed runs on uthread, so disconnect() joined that thread from itself) and makes recv() wake on disconnect rather than waiting out its timeout.

Settings snapping back a second later

A brief link glitch left the frame parser stranded mid-stream for the rest of the session: bytes before the first START_MARKER were concatenated into the message, and a second one threw. 60/61/62 are escaped inside a frame, so a start marker unambiguously begins one — both cases now resync on it instead.

_waitForAck() read exactly one frame and assumed it was the ACK, but the device pushes unsolicited notifications on the same stream (a state change, a press of the headset's own button). It took _seqNumber from the wrong frame, and the device dedupes on that, so the next command was silently discarded as a duplicate — DSEE wouldn't toggle at all, while ASC and the EQ snapped back on the next poll.

Also: requestAmbientState() matches sub-type 0x17 rather than any 0x67, so a notification with a different layout is no longer parsed as the reply; the read-back no longer overwrites a change that hasn't been sent yet (isChanged() went false, so the command was never sent at all); and the 2s poll stopped republishing dsee/eqPreset/eqBands, which it never re-read — failed writes roll back explicitly now, and the EQ sliders no longer fight the timer mid-drag.

Equalizer

Manual showed the wrong bands

The band values were read once, on connect, where the device reports the curve of whatever preset happens to be active. setEqualizerPreset() then sent 58 00 preset 00 and updated the cached preset byte alone, so selecting Manual left the sliders on the previous preset's curve instead of the custom one the device restores — and dragging a slider from there wrote those stale values back over the stored curve.

Preset writes now re-read with requestEqualizer(), after the property lock is released (it takes the same non-recursive mutex) and guarded so a failed read-back doesn't report a write that already landed as failed. Both UIs republish the bands when the write completes; neither re-read them on any other path.

Icon

Apple's grid: 824 body centered in 1024, rounded corners, subtle shadow.

P.S. Let me know if it's better to split this PR into few smaller PRs