[SET pageicon help] [SET title The Slim TCP Protocol] [SET techinfo 1] [INCLUDE helpheader.html]
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.
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 rptr - Position of read pointer in players buffer? u32 wptr - Position of write pointer in players buffer? 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 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...
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"
[INCLUDE helpfooter.html]Sends VFD data to the client.
The data is the vfd data to send in the same format as for the SLIMP3 protocol.