Server
From giantdisc
Contents |
The GiantDisc Server
General concepts
A complete GiantDisc system consists of the following three parts:
| Server Machine | Music Station | Remote Control | |
| Role | stores music and database | plays music | controls music selection and playback |
| Hardware | Pentium class processor, large harddisk | Pentium class processor or i386 class processor with mp3 hardware decoder | Palm handheld, Serial cable or Bluetooth/WLAN adapter |
| Software | Linux/Unix system, MySQL database server, Web server (optional), NFS server (optional) | Linux/Unix system, GiantDisc server script gdd.pl, Web browser (optional), NFS client (optional) | PalmOS 2.0 or higher, GiantDisc client software |
Notice that in many (most?) cases the Server Machine and the Music Station are physically the same machine. But it is alternatively possible to attach multiple music stations to a server (see below). #GiantDisc_in_a_Local_Network
GiantDisc in a Local Network
In a networked architecture, the server acts as a database-, a (mp3) file- and a web-server.
A music station does not store the mp3 files. The possibly diskless music station accesses to them on the server via the Network File System (NFS). The station runs an instance of a server script which communicates with the database on the server and the Palm remote control application. It also loads and decodes mp3 files and sends them to it's soundcard.
Alternatively, music track can also be played on a general web pad, which is capable to play mp3 music files. The mp3 files are then managed and loaded via a standard web interface.
GiantDisc supports mp3 streaming devices as the Exstreamer. A mp3 streaming device can be seen as a network attached soundcard. The nice thing is, that a streaming device is cheap and easy to set up, and that a single server can serve a large number of them. The Exstreamer also features a serial port, and it is able to tunnel all serial communication through the network connection. So no problem to connect the Palm in a snap. GiantDisc is also capable of re-encoding ogg-vorbis and flac audio files to a mp3 stream on-the-fly. #The_server_script_gdd_pl
The server script gdd.pl
Invoking gdd.pl
- manually: issue the command gdd.pl on the shell prompt.
- automatically on startup:// the server can automatically be started when the system boots. The server should be run as the user music, and not root. The following works well for me on a RedHat system: Add the command su --command="/home/music/bin/gdd-wrapper.sh" music&to the end of the file/etc/rc.d/rc.local See here for a description how this can be on a Debian system.
* periodically with cron job:// The system can periodically check if an instance of the server script is running and (re)start it, if no running server script was found. The command crontab /home/music/bin/cronfile-1per-h adds a crontab file which executes the script /home/music/bin/gdd-wrapper.sh every hour. This wrapper script (re)starts the server gdd.pl if necessary (like a watchdog).
If the GiantDisc server script gdd.pl is started from within a cron job or at system boot, no parameters can be specified on the command line. Nevertheless, parameters can be passed if the are specified in the configuration file .gdconfig.
Command line options
Get a list of command line options with the command gdd.pl -h or gdd.pl --help.
Currently available options:
--dbhost (string) address or hostname of mysql database server
Default value: localhost
--commmode (number) Communication mode between Palm and server.
1: serial line RS232
2: TCP/IP - as server - accepts connections
3: mixed RS232 & TCP/IP mode
Default value: 2
--serialdevice (string) Serial device at which Palm is connected.
Only used if --commmode 1
Default value: /dev/ttyS0
--serialspeed (number) Communication speed over serial line in
Bits per second.
Only used if --commmode 1
Default value: 19200
--tcpiphost (string) IP address on the server which accepts socket connections.
Only used if --commmode 2
Default value: localhost
--tcpipport (number) Port used for TCP/IP communication mode.
Only used if --commmode 2
Default value: 26468
--playertype (number) Specifies how and where the audio files
are played
0: local soundcard, oss driver, aumix
20: network attached mp3 streaming device
(barix exstreamer)
Default value: 0
--playerhost (string) address or hostname where the audio stream
is sent to.
Only used if --playertype 20
Default value: localhost
--playerdevice (string) Device where decoded mp3 audio stream is
sent to.
0: sound device of local soundcard
(i.e. /dev/dsp) (currently ignored)
20: port number of audio streamer (2020
for barix exstreamer)
Default value: 2020
--logtarget stdout, logfile Target, where log-messages of the
or devnull server script should be sent to.
'stdout' sends to standard out, 'logfile'
sends to a log file in ~music/tmp and
devnull supresses all logging.
Default value: stdout
Configuration File
All command line options including a few additional options can be specified in the configuration file .gdconfig. All options are commented in the file itself, so it should be self-explanatory. If an option is set on the command line and in the configuration file, then the command line takes precedence.
===Invocation examples===
These examples all assume that a Palm client controls one GD server script (see below for different scenarios).
Palm controls server over serial cable
gdd.pl --commmode 1 --serialdevice /dev/ttyS1
Palm controls server over tcp/ip connection (i.e. infrared)
gdd.pl --commmode 2
mp3 files are streamed to an exstreamer (network streaming device), the palm is attached to the extreamer's serial port and communicates with it at 9600 bits/sec (exstreamer serial redirection at port 12302)
gdd.pl --commmode 3 --playertype 20 --playerhost 192.168.1.30 --tcpiphost 192.168.1.30
#One_Client_Controlling_Multiple_Servers
One Client Controlling Multiple Servers
A Palm client application program can only control one GD server at a time, and it is not possible to have multiple installations of the client application on a single Palm device.
If more than one server is to be controlled with a Palm, a connection for each server instance should be defined in the communication settings dialog of the Palm client.
In order to control a server, just connect to it. This can be done on-the-fly, without having to leave and re-enter the client application. Furthermore, it is possible to disconnect from server A, connect to server B and re-connect later to server A at any time. If you disconnect from a server, it will just continue it's normal operation: playing tracks, recording CDs, waiting for commands, etc.
#Multiple_Clients_Controlling_One_Server
Multiple Clients Controlling One Server
Important Note: This section and the use of listeners is obsolete as of GiantDisc 1.44
The nature of a GD server is that one GD server script is always controlling exactly one audio channel (one soundcard, or one streaming channel). Controlling one audio channel through GD concurrently by multiple GD clients is a bit tricky. Special care must be taken to avoid conflicts and communication deadlocks. For this reason it is not possible to have more than one instance of a GD server being connected to the same audio channel.
If a server is to be controlled by more than one client, a command listener has to be running for each client (See illustration at the right). When a listener receives a command, it is forwarded to the server. If the server returns results, they are directly sent back to the client through the listener. Notice that the server and the listeners may run on different hosts.
The purpose of the listeners is that they are serializing the commands that are received by the entirety of clients. The server will either be waiting, or processing exactly one command. Concurrently arriving commands will be queued up and processed later. Making the clients wait until the server is ready is is usally no problem. A typical communication transaction takes 1-2 seconds. Even with many connected clients, the subjective perception should be an immediately responding server.
Make sure, that there are no conflicting TCP/IP socket connections. For example: If the server and the listeners are all running on the same host, each TCP/IP connection needs its own port number.
In the following example a server is started which is accepting commands through TCP/IP on port 26468. Two listeners are connected to the server: one is listening on the serial port (comm-mode 1) and the other on TCP/IP port 26469.
> gdd.pl --commmode 4 & > gdd-listener.pl --commmode 1 --serialdevice /dev/ttyS1 --serialspeed 19200 --serverhost 192.168.1.1 --serverport 26468 & > gdd-listener.pl --commmode 4 --tcpiphost 192.168.1.1 --tcpipport 26469 --serverhost 192.168.1.1 --serverport 26468 &
Supported Audio Formats
GiantDisc was initially designed to serve as a mp3 jukebox. However, as other audio standards became important, the design has been extended and generalized. These are the currently supported audio formats:
| mp3 | ogg | flac | |
| playback |  requires mpg123 | requires ogg123 | requires flac and rawplay
|
| pause, rewind, fast forward | | |
|
| recording CDs | requires lame | requires oggenc | requires flac
|
| interactive import over inbox | | |
|
| shell batch import including metadata interpretation | id3v1 tags | vorbis-comment tags | metaflac vorbis-comment tags
|
| trim audio file | | ||
| export db to metadata tags | id3v1 tags | ||
| export to filesystem | | |
|
| streaming (receive external sources) | | | |
| send mp3 stream (re-encode ogg or flac to mp3 on-the-fly) | | |
|
| synchronizing between servers | | |
|
Ogg Vorbis is an audio encoding format like mp3, but it is completely license- and patent-free. Independent test have shown, that ogg is slightly better and mp3 at higher bitrates > 128kbps and and considerably better at lower bitrates. There is a free implementation available at http://www.vorbis.com
Flac is a lossless audio coding algorithm and format. A flac file has typically about 55% the size of a wav file. There is a free implementation available at http://flac.sourceforge.net #Supported_Unix_Versions
