Packet Types

Background

The protocol used by Pioneer professional DJ equipment to communicate and coordinate performances can be monitored to provide useful information for synchronizing other software, such as light shows and sequencers. By creating a “virtual CDJ” that sends appropriate packets to the network, other devices can be induced to send packets containing even more useful information about their state. This document details what has been learned so far about the protocol, and how to accomplish these tasks.

This information was discovered by studying packet captures and with the help of dysentery, a bespoke protocol analysis tool written in Clojure. This document was created in parallel with the development of dysentery to help spread the knowledge to other developers using other languages.

Once enough had been understood to start interacting in useful ways with the devices, the Beat Link library was written to provide a convenient interface for other programs running in the Java virtual machine. Eventually enough was learned about the format of the media databases on USB drives and SD cards inserted in the players to implement Crate Digger, another Java library which parses them, and whose analysis is part of this documentation site as well.

Other implementations include prolink-go and python-prodj-link.

Known UDP Packet Types

Although there are occasionally TCP connections involved in the protocol, especially for track metadata queries, most of the features of the protocol are implemented through UDP packets sent to a handful of ports, often to the network broadcast address, but occasionally to individual devices. These are discussed in more detail in their individual sections, but here is a breakdown of the packet types which have been discovered so far.

DJ Link packets seem to all start with a fixed sequence of ten bytes, 51 73 70 74 31 57 6d 4a 4f 4c. This is followed by a byte which (combined with the port on which it was received) identifies what kind of information is found in the packet.

Port 50000 Packets

Packets sent to port 50000 seem primarily related to announcing the devices present on the network, and negotiating the channel (device) number assigned to each.

Kind Purpose

00

First-stage channel number claim, e.g. mixers and CDJs.

01

Mixer assignment intention, sent by mixers to devices connected to channel-specific ports.

02

Second-stage channel number claim, e.g. mixers and CDJs.

03

Mixer channel assignment, sent by mixers to devices connected to channel-specific ports.

04

Final-stage channel number claim, e.g. mixers and CDJs.

05

Mixer assignment finished, sent by mixers to devices connected to channel-specific ports.

06

Device keep-alive (still present on network), e.g. mixers and CDJs.

08

Channel Conflict, sent when a device sees another trying to claim the same channel.

0a

Initial device announcement, e.g. mixers and CDJs.

Port 50001 Packets

Packets sent to port 50001 seem primarily related to beat synchronization (the first element of the protocol that we figured out), and mixer features like Fader Start and Channels On Air.

Kind Purpose

02

Fader Start

03

Channels On Air

26

Master Handoff Request

27

Master Handoff Response

28

Beat

2a

Sync Control

Port 50002 Packets

Packets sent to port 50002 provide more detailed device status (they are crucial for figuring out what track a player is playing, at what tempo, and how much has been played), as well as finding out information about the media that has been mounted in a particular slot. They also support remote-control features such as instructing players to load tracks.

Kind Purpose

05

Media Query

06

Media Response

0a

CDJ Status

19

Load Track Command

1a

Load Track Acknowledgment

29

Mixer Status

34

Load Settings Command

Port 50004 Packets

Packets sent to port 50004 provide link cue audio data between supported players and mixers.

Kind Purpose

1e

Audio Data

1f

Audio Handover

20

Audio Timing