Open-source project
NicholasSlattery/sony-head-tracker avatar
NicholasSlattery/sony-head-tracker

Sony Head Tracker: Using WH-1000XM5 Motion Sensors as a Windows and macOS Head Tracker

Use the motion sensors inside Sony headphones as a low-latency Windows and MacOS head tracker for OpenTrack and simulator games.

581 stars25 forksC++NOASSERTION

At a glance

What is it?
An unofficial C++20 bridge that reads the Android Head Tracker HID sensor inside compatible Sony headphones and sends yaw, pitch and roll to OpenTrack. The setup is short, but the Windows cold-boot pairing quirk is the first thing a new user hits.
Who is it for?
Adopt it if you already own a compatible Sony headset, run Windows 11 or macOS 14 or later, and want head tracking in OpenTrack without a webcam or IR clip. Skip it if your headset does not expose the Android Head Tracker HID protocol, or if you need a signed, notarized macOS build, since the prebuilt package is ad-hoc signed only.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 34 days ago.
What is it written in?
Mainly C++, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The gap Sony Head Tracker fills for sim racers and flight simmers

Head tracking in simulators has traditionally meant extra hardware: a webcam running face tracking, an infrared clip mounted on a cap, or a dedicated tracker. Sony Head Tracker takes a different route. It reads the motion sensor that already sits inside compatible Sony Bluetooth headphones and earbuds, the same sensor Sony uses for spatial audio, and republishes that orientation as yaw, pitch and roll.

The README is explicit about what is not needed: no webcam, no infrared tracker, no additional hardware, no firmware modification and no custom kernel driver. That is the whole pitch. The project was originally developed and tested for the Sony WH-1000XM5, and the README calls that model the reference device, but it now targets any Sony headset that exposes the standard Android Head Tracker HID protocol.

The audience is narrow and specific. You need a compatible Sony headset, a Windows 11 or macOS 14 or later machine, and a game or application that consumes head tracking through OpenTrack. Racing simulators and flight simulators are the stated use cases. If you do not already own one of these headsets, the project has nothing to offer you, because the sensor is the entire input.

How the HID sensor data becomes OpenTrack output

The data path has four stages. First, the headphones expose an Android Head Tracker sensor over Bluetooth HID. Second, Sony Head Tracker discovers that sensor: on Windows it looks for compatible head-tracking sensors automatically, and on macOS the README states the port discovers devices by the Android Head Tracker HID descriptor rather than by model name, VID/PID, report ID or report length. That descriptor-based matching is why the same binary can work across the Sony range without a per-model table.

Third, the application reads live orientation and gyroscope data and converts it into yaw, pitch and roll. Fourth, it streams that output in one of two ways. For OpenTrack, the README says to select UDP over network as the input and use port 4242. For your own code, the application emits one JSON object per sample on port 4243, documented in docs/PROTOCOL.md.

Two details matter for anyone integrating this. The JSON stream is a local stream, not a remote API, so consumers run on the same machine. And the two ports are separate: 4242 carries the OpenTrack-facing output, 4243 carries raw samples for custom consumers. The repository also ships a read-only compatibility probe for testing additional Sony models, which is the right tool when you want to know whether an unlisted headset exposes the protocol before committing to the setup.

Installing Sony Head Tracker on Windows 11 and running it with OpenTrack

On Windows the installation is a download, not a build. The README points to sony-head-tracker.exe in the latest release, and notes that building it yourself is one cl command if you prefer. Download the executable, then pair your compatible Sony headphones or earbuds through Windows 11.

Open the application. According to the README, it automatically discovers compatible head-tracking sensors, displays live orientation data, and streams tracking output while it is open. One step catches nearly every first-time user on a cold boot:

The README is direct about this: Windows very often pairs a Sony headset but does not create the head-tracker sensor node until something nudges it, so pressing Repair Tracker and approving the single administrator prompt is the normal first step, not a sign that anything is broken. After the app reopens, the headset should appear.

With the sensor visible, point OpenTrack at the stream. Select UDP over network as the input, set the port to 4242, and press Start. Then press Recenter in Sony Head Tracker, or use the Ctrl+Alt+C shortcut, while facing forward.

For your own code, the alternative to OpenTrack is the JSON stream. The README says to read one JSON object per sample from port 4243, with the object format documented in docs/PROTOCOL.md. If you are writing a consumer, that document is the contract; the README does not restate the field layout.

macOS 14 and later: prebuilt package versus building from source

The macOS port includes a native SwiftUI application and a command-line bridge. The README offers three ways to run it and says you only need one.

Option 1 is the prebuilt package, sony-head-tracker-vX.Y.Z-macos-universal.zip from the latest release. It contains the SwiftUI app and the CLI bridge as universal binaries for Apple Silicon and Intel, requires no developer tools, and needs macOS 14 or later. The catch is signing. The app is ad-hoc signed but not notarized, so Gatekeeper flags the first launch: right-click or Control-click the app and choose Open. If macOS does not offer Open, the README directs you to System Settings > Privacy & Security, where a blocked-app notice appears and you click Open Anyway. After that, allow Sony Head Tracker under System Settings > Privacy & Security > Input Monitoring, then quit and reopen it.

Option 2 builds the native application without a separate CMake step. From the repository root, run the build script:

bash
./script/build_and_run.sh

The script builds the committed Xcode project and opens SonyHeadTracker.app. Building from source requires full Xcode selected with xcode-select. Option 3 is the command-line bridge, which additionally requires CMake 3.25 or later. The split is worth noting: the packaged route avoids Xcode entirely, while both source routes assume a full toolchain.

Where Sony Head Tracker is the wrong tool

The largest limitation is hardware compatibility, and the README does not hide it. The project supports any compatible Sony headset that exposes the Android Head Tracker HID protocol, but that is a protocol requirement, not a brand requirement. A Sony headset that does not expose the sensor cannot be made to work by this application, and the README does not claim otherwise. The compatibility probe exists precisely because the supported set is not a fixed list.

The macOS distribution has a second, practical limitation. The prebuilt package is ad-hoc signed and not notarized, which means Gatekeeper blocks the first launch and you must override it manually through right-click Open or Privacy & Security. Anyone who needs a notarized binary for managed or locked-down machines will not get one from the release page.

There is also an operational dependency worth stating plainly. On Windows, the sensor node may not exist after a cold boot until Repair Tracker runs with an administrator prompt. That is an extra step every time, and the README presents it as normal rather than as a bug being worked around.

Finally, the project is a bridge, not a tracker. It produces yaw, pitch and roll; it does not consume them. Without OpenTrack or your own consumer on port 4243, the application has nothing to drive. If your simulator does not support OpenTrack-style input, this project is not the missing piece.

How this differs from webcam and infrared head trackers

The obvious alternative is a webcam-based tracker such as OpenTrack's own face-tracking input, or a dedicated infrared setup with a clip and camera. Those approaches do not care which headphones you wear, and they do not depend on a Bluetooth HID sensor being present. The trade-off is hardware: a camera pointed at your face, lighting sensitivity in the webcam case, and an extra device to mount and calibrate in the infrared case.

Sony Head Tracker inverts that. There is no camera and no clip, because the sensor is already on your head. The cost is total dependence on the headset: the tracked object and the audio device are the same piece of hardware, so you cannot swap to a different pair of headphones and keep tracking.

The latency claim in the repository description is low latency, which follows from reading a local HID sensor over Bluetooth instead of processing video frames. The README does not publish latency figures, so treat the descriptor as a design intent rather than a measured number. The more useful comparison for most readers is simpler: if you already own a compatible Sony headset and play sims, this removes a piece of hardware from your desk. If you do not, a webcam tracker remains the general-purpose option.

Maintenance, licence and what the repository does not settle

The repository is not archived, and the last push was on 2026-08-28. Releases are recent and versioned: v2.0.0 on 2026-07-05, v2.1.0 on 2026-07-09, and v2.2.0 on 2026-07-12. That cadence over a single week in July suggests active iteration at that point; the August push is the most recent signal available.

Licensing needs a caveat. The README carries an MIT badge and links to LICENSE, but the repository metadata reports the licence as NOASSERTION, meaning the platform could not classify it automatically. The LICENSE file is the authoritative text, and the MIT badge in the README is the project's own claim. If you plan to redistribute the binary or embed the code, read LICENSE rather than the badge.

Upgrade cost looks low by design. Windows users replace a single executable; macOS users replace an app bundle or rerun the build script. The committed Xcode project means the macOS build does not depend on a generated CMake configuration, so the source route is stable across releases. The JSON protocol on port 4243 is the one interface a custom consumer depends on, and the README points to docs/PROTOCOL.md rather than versioning the stream in the README itself, so check that document when upgrading if you have written your own reader.

What the repository does not settle: there is no documented rollback procedure, no stated support matrix of tested Sony models, and no published latency measurement. The compatibility probe is the mechanism for answering the model question yourself.

Editorial conclusion

Adopt it if you already own a compatible Sony headset, run Windows 11 or macOS 14 or later, and want head tracking in OpenTrack without a webcam or IR clip. Skip it if your headset does not expose the Android Head Tracker HID protocol, or if you need a signed, notarized macOS build, since the prebuilt package is ad-hoc signed only. Before relying on it, verify three things: that your model appears in the compatibility probe, that OpenTrack receives data on port 4242, and that the Repair Tracker step works on your machine after a cold boot.

Frequently asked questions

Is there a tracker for Sony headphones?

Yes. Sony Head Tracker uses the Android Head Tracker sensor exposed by compatible Sony Bluetooth devices as a real-time head tracker on Windows and macOS, sending yaw, pitch and roll to OpenTrack or to your own applications. It is an unofficial bridge and is not affiliated with or endorsed by Sony.

How can I locate my lost Sony headphones?

Sony Head Tracker does not do this. It reads motion sensor data from headphones you are wearing and streams orientation to OpenTrack; the README describes no location, find-my-device or proximity feature.

Can you track Sony headphones if stolen?

The README does not support this. Sony Head Tracker is a head-tracking bridge for simulators and custom applications, and the documented features cover orientation, quaternion and gyroscope data, not theft recovery or device location.

Do Sony earphones have tracking?

Sony Head Tracker supports compatible Sony headphones and earbuds that expose the Android Head Tracker HID protocol, and the README notes the project now supports the wider Sony range beyond the WH-1000XM5 reference device. Whether a specific model exposes that sensor is what the read-only compatibility probe is for.

Official sources

  1. Issues
  2. NicholasSlattery/sony-head-tracker on GitHub
  3. README
  4. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/nicholasslattery-sony-head-tracker.svg)](https://hysenlabs.com/projects/nicholasslattery-sony-head-tracker)