[% pageicon = 'help' %] [% pagetitle = 'The SlimProto TCP Protocol:' %] [% techinfo = '1' %] [% PROCESS helpheader.html %]

#### SlimProto Protocol

The SlimProto protocol is the new protocol developed for the squeezebox and replaces the SLIMP3 one. It is designed to allow the players to communicate effectively over WANs as well as LANs.

This document describes the SlimProto for Squeezebox firmware versions 20 and above.

The server listens on TCP port 3483 for connections by players. To register a player with the server, they exchange "helo"s and than any of the commands below are valid.

The client also listens on UDP port 3483 for SlimProto commands from the server it has already established a TCP connection with.

The byte order is critical for several of the fields. The best way to check this out is to look at the server source code.

#### Client -> Server Communications

A command to the server consists of three parts:

> 1. The 1st 4 bytes specify the operation. The following operations are supported:

> - HELO
> - IR (note the two spaces after IR)
> - RESP
> - STAT
> - BYE!

> 2. The 2nd part (of four bytes) is simply the length of the data packet (in Network order).

> 3. The 3rd part is the data itself.

Each of the operations above are detailed below:

HELO

> This alerts the server to a clients presence and is the first thing normally transmitted by a client powering up.

> Data Length: Fixed at 10 bytes.

> Format:

> DeviceID | 1 byte | The Device ID of the player. '2' is the squeezebox
> Revision | 1 byte | A number specifying the firmware revsison
> MAC 0-5 | 6 bytes | The player's MAC address
> WLanChannelList | 2 bytes | A list of 802.11 channels that are enabled on a given device as a bitfield. 0x07ff means that channels 0 through 11 are enabled, which means it's configured for the US.

"IR " (Note the two spaces to make it up to 4 characters.)

> One of these packets is recieved for each IR code recieved by the player.

> Data Length: Fixed at 10 bytes.

> Format:

> Time | 4 bytes | Time since player startup in ticks (@1Khz)
> Format | 1 byte | Code Format (ignored by the server for now - Code represents type of IR code - NEC, JVC or Sony)
> NoBits | 1 byte | Length of IR Code (ignored by the server for now - 16 bits for JVC, 32 bits for NEC?)
> IRCode | 4 bytes | the IR Code itself (upto 32 bits)

RESP

> Response from the player - currently unused. The client is reporting back the status of the data server response.

STAT

> These are sent by the player in response to commands and periodically when there are no commands as a sort of keep-alive. They inform the server of the status of various player internals.

> Format:

> u32 | Event Code (a 4 byte string)
> u8 | Number of consecutive CRLF recieved while parsing headers
> u8 | MAS Initalized - 'm' or 'p'
> u8 | MAS Mode - serdes mode?
> u32 | buffer size - size, in bytes, of the player's buffer memory
> u32 | fullness - number of bytes of audio data in the player's buffer memory
> u64 | Bytes Recieved
> u16 | Wireless Signal Strength (0-100 - Larger values mean hardwired)
> u32 | jiffies - a timestamp from the player (@1Khz)

> The following event codes are (currently) used:

> STMu | data underrun
> STMe | connection established
> STMh | received end of headers from data server
> STMa | autostart of playback occured
> STMf | connection closed
> STMp | playback paused
> STMr | playback unpaused

> The event code is a method of triggering events in the server. The only currently used event is "STMu" which occurs on buffer underrun. This causes the server to switch to the next track.

> The Bytes Received field is how many data bytes the player has recieved (since it started playing?). This and the read/write pointers are used to update the elapsed time count.

BYE!

> The player is disconnecting.

> If the first data byte to this command is 0x01 then the player is going out for an upgrade...

#### Server -> Client Communication

Data from the server to the player consists of 2 bytes of length data (in network order), a 4 byte command header, then the command data itself.

Command: "strm"

> This takes 16 bytes data of the form:

> $command | 1 byte | 's' start, 'p' pause, 'u' unpause, 'q' stop
> $autostart | 1 byte | (buffer threshold to start playing at) '0' off, '1' 25%, '2' 50%, '3' 75%, '4' 100%
> $formatbyte | 1 byte | 'p' for pcm data, 'm' for mp3
> $pcmsamplesize | 1 byte | '0' = 8, '1' = 16, '2' = 20, '3' = 32 usually '1' ('?' for mp3)
> $pcmsamplerate | 1 byte | '0'=11kHz, '1'=22kHz, '2'=32kHz, '3'=44.1kHz, '4'=48kHz usually '3' ('?' for mp3)
> $pcmchannels | 1 byte | '1'=mono, '2'=stereo usually '2' ('?' for mp3)
> $pcmendian | 1 byte | '0' = big, '1' = little ('1' for wav, '0' for aif, '?' for mp3)
> $prebuffer_slience | 1 byte | usually 5 (mpeg prebuffer x frames of silence)
> $spdif_enable | 1 byte | '0'=auto, '1'=on, '2'=off usually 0
> | 1 byte | reserved
> $server_port | 2 bytes | Server Port to use (9000 is the default)
> $server_ip | 4 bytes | 0 means use IP of control server

> This is followed by an HTTP header itself. This is used to obtain the stream data eg:

> GET /stream.mp3?player=$client-id HTTP/1.0
> (Authorization: Basic $password)
> (blank line)

> The Auth line is only sent if authorization is in use. $client-id is the usually the MAC address of the player and $password is a password generated by the server.

Command: "i2c"

> Sends an i2c command to the client.

> The data is the i2c command to send in the same format as for the SLIMP3 protocol.

> This is used to control the setup of the mas chip. Volume commands are embedded in this.

Command: "vfdc"

> Sends VFD data to the client.

> The data is the vfd data to send in the same format as for the SLIMP3 protocol.

Command: "vers"

> Sends server version string to the client.

> The data is the human readable version information for the server.

[% PROCESS helpfooter.html %]