Switch 2 Pro Bluetooth audio: public-source research, 2026-09-08¶

Historical record. This preserves the source, tests and limitations recorded at the time; it is not current setup guidance. See the documentation index.

Outcome and scope¶

This bounded public-source pass found a real decrypted console/controller capture and a useful console-facing emulator logger foundation, but did not find a verified physical Switch 2 Pro Bluetooth headphone playback implementation or a downloadable successful headphone stream. This is a finding about the inspected material, not proof that no such work exists.

The work was read-only apart from this report: GitHub/web source inspection and in-memory parsing of a public capture archive. No controller, app, task-scheduler, Bluetooth, firmware, or installed-program state was changed. No capture file was written locally. Pairing secrets and microphone/voice payloads are deliberately excluded from this report.

BlueRetro: genuine decrypted capture, older firmware¶

Source: BlueRetro issue 1249, corrected decrypted archive, posted June 17, 2025. The linked ZIP attachment contains decrypted Pro and GameCube PCAP files and their original PCAPNG files. The author describes correcting the Nordic header's encryption flag after decryption.

The decrypted PCAP entries were parsed in memory using the little-endian PCAP record format and Nordic v3 framing checked against the Wireshark Nordic BLE dissector. The analysis admits CRC-valid, encryption-flag-clear data packets and complete L2CAP ATT PDUs. No non-empty clear continuation packets or fragmented clear ATT starts were encountered. Counts are capture records, not retransmission-deduplicated transactions. A redirected in-memory tshark invocation was rejected by tool policy before execution; this report therefore does not claim independent Wireshark decoding of these entries.

Pro file: sw2_pro2_reconn_sc2_rumble_crackle.pcap.

• Frames 3617 and 3961 return firmware information 1001010110780000010104020C000000FFFFFFFF. Using the documented firmware-info fields, this is Pro controller firmware 1.1.4, Bluetooth patch 12.0.0, with FF FF FF FF rather than an installed DSP version in the final field.
• Frame 3972, 4.639188 seconds from the beginning of the capture, sends 18 91 01 01 00 00 00 00 through 0x0016, after the Pro report's 33-byte prefix.
• Frame 3977, at 4.649594 seconds, responds on 0x001a with exactly 18 00 01 01 10 78 00 00. This is an eight-byte, non-normal response, with byte 1 equal to 00 rather than documented response direction 01 and no state body. It fails the current lab's successful 16-byte 18/01 admission contract. It does not demonstrate modern audio-state semantics or a successful audio setup.
• The two acknowledged feature startup requests use mask 0x27 in this historical trace. This does not replace the later pinned console sequence's 0x2f evidence.
• No decoded 17/02 configuration, 18/03 command, headset-notification subscription, or headphone output stream was found.

Do not assign today's audio UUID to this capture's numeric handle¶

The reconnect capture does not enumerate the complete characteristic UUID table. Its two Read-By-Type transactions read custom ...d281 and ...d283 values; they are not 0x2803 characteristic discovery. Numeric handles alone cannot establish the headphone UUID.

The author's contemporary GATT table instead places Generic Access at 0x002b, a 0x2803 characteristic declaration at 0x002c, and Device Name at 0x002d. That table does not identify 0x002c as headphone output. The later ndeadly GATT documentation explicitly notes that updated Pro firmware adds headset attributes, including the headphone characteristic ending b06.

The old firmware response and contemporary table support the inference that this trace predates the modern headset-capable layout. They do not prove the complete live GATT table from this reconnect PCAP itself.

Coverage limitation¶

The Pro capture retains encrypted non-empty packets: an earlier connection has 1,748 peripheral-to-central length-74 packets; the inspected reconnect has nine central-to-peripheral length-53 packets and four peripheral-to-central length-74 packets. These were not treated as plaintext or classified by guessed payload content. Therefore, the zero counts above mean no such traffic among decoded complete ATT records, not an assertion that every byte of every connection was decoded. The file is valuable for historical initialization/rumble and the non-normal 18/01 response, but not a successful headphone-codec donor.

Console-facing logger foundation, not a working audio donor¶

espp PR 765, inspected at head 65c28f9955dfdf5ce946cf1b98e4237b9d87f427, implements Switch 2 Pro BLE emulation. The author reports console pairing, input, and reconnection on ESP32-C6/S3. Its headphone characteristic ending b06 is registered and writes can reach a passive hexadecimal logger; it does not supply headphone encoding, playback, or validated audio initialization semantics.

This is a possible separately powered microcontroller plus real-console capture foundation. It is not a PC-only solution, a passive sniffer, a captured console audio stream, or evidence that a physical Pro controller accepts any candidate codec. The related ESP32-BLE5-NSController-Emulator advertises a headphone characteristic but its checked write dispatch does not implement that endpoint. Neither finding authorizes hardware changes or establishes that the console would start audio without further protocol work.

Other leads checked¶

• ndeadly research: inspected issues, PRs, discussions, comments, forks, and relevant commit changes. A final freshness check found two new hid_reports.md commits: 0x07 NFC-byte removal and 0x05 motion types/ranges. Those diffs contain no audio setup or new capture. Earlier checked motion/reconnection captures remain distinct from headphone playback evidence.
• switch2mac audio investigation and capture analysis: explicitly incomplete playback research; the analyzed 112-byte controller-to-Mac notifications are not console-to-controller headphone packets. Inspected PR/fork changes did not provide a successful headphone capture.
• switch2bridge-macos issue 14 and its protocol-tooling fork: useful button, calibration, USB, and motion evidence. The discussion distinguishes the ...f9 headset input characteristic from other report layouts; no successful console-origin headphone stream was supplied in the inspected discussion/tree.
• german77/JoyconDriver: useful dissector fields, input audio-status marker, and DSP-region identification; no checked headphone packet codec/capture implementation.
• pexserver ProCon2Audio.js: an apparent audio lead that is browser Web Audio playback/analysis. setHeadphoneOutput only stores a flag and logs; Music.js only delegates to it. The checked core uses WebUSB/WebHID, and its plan lists Bluetooth as future work. It is not controller-jack playback.
• Switch2ProWirelessViiper README: explicitly excludes headphone, speaker, and microphone audio. Switch2Connect likewise explicitly excludes wireless Pro controller audio.

What would materially change the implementation evidence¶

A later-firmware, real-console capture that includes actual UUID-to-handle discovery, the headset insertion/state transition, command setup and replies, and a non-silent console-to-headphone stream would answer questions this pass cannot. A verified working physical-controller implementation with the same provenance would also qualify. Another accepted host write, a motion notification, a USB-audio implementation, or a named but unimplemented audio endpoint would not by itself establish Bluetooth headphone playback.