[SET pageicon help] [SET title The Slim TCP Protocol] [SET techinfo 1] [INCLUDE helpheader.html]

Slim TCP Protocol

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

The server listens on 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 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?
u32rptr - Position of read pointer in players buffer?
u32wptr - Position of write pointer in players buffer?
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 ot 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.

[INCLUDE helpfooter.html]