[% 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:

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:

DeviceID1 byteThe Device ID of the player. '2' is the squeezebox
Revision1 byteA number specifying the firmware revsison
MAC 0-56 bytesThe player's MAC address
WLanChannelList2 bytesA 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:

Time4 bytesTime since player startup in ticks (@1Khz)
Format1 byteCode Format (ignored by the server for now - Code represents type of IR code - NEC, JVC or Sony)
NoBits1 byteLength of IR Code (ignored by the server for now - 16 bits for JVC, 32 bits for NEC?)
IRCode4 bytesthe 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:

u32Event Code (a 4 byte string)
u8Number of consecutive CRLF recieved while parsing headers
u8MAS Initalized - 'm' or 'p'
u8MAS Mode - serdes mode?
u32buffer size - size, in bytes, of the player's buffer memory
u32fullness - number of bytes of audio data in the player's buffer memory
u64Bytes Recieved
u16Wireless Signal Strength (0-100 - Larger values mean hardwired)
u32jiffies - a timestamp from the player (@1Khz)

The following event codes are (currently) used:

STMudata underrun
STMeconnection established
STMhreceived end of headers from data server
STMaautostart of playback occured
STMfconnection closed
STMpplayback paused
STMrplayback 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:

$command1 byte's' start, 'p' pause, 'u' unpause, 'q' stop
$autostart1 byte(buffer threshold to start playing at) '0' off, '1' 25%, '2' 50%, '3' 75%, '4' 100%
$formatbyte1 byte'p' for pcm data, 'm' for mp3
$pcmsamplesize1 byte'0' = 8, '1' = 16, '2' = 20, '3' = 32 usually '1' ('?' for mp3)
$pcmsamplerate1 byte'0'=11kHz, '1'=22kHz, '2'=32kHz, '3'=44.1kHz, '4'=48kHz usually '3' ('?' for mp3)
$pcmchannels1 byte'1'=mono, '2'=stereo usually '2' ('?' for mp3)
$pcmendian1 byte'0' = big, '1' = little ('1' for wav, '0' for aif, '?' for mp3)
$prebuffer_slience1 byteusually 5 (mpeg prebuffer x frames of silence)
$spdif_enable1 byte'0'=auto, '1'=on, '2'=off usually 0
 1 bytereserved
$server_port2 bytesServer Port to use (9000 is the default)
$server_ip4 bytes0 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 %]