#A4# #Overview# #para_server# #Incoming connections arrive via TCP at the dispatcher which creates a command handler process for each connection. After the connecting client has been authenticated, the command handler propagates the incoming request either to the audio file selector (afs) or to the virtual streaming system (vss). Results are sent back to the client. afs maintans the audio file database and is responsible for selecting and loading audio files while vss controls the paraslash senders. When vss needs to stream an audio file it requests an open file descriptor from afs and feeds small chunks of data (e.g. mp3 frames) to the senders which send the chunks to all connected clients.# ## ## #dispatcher# #senders# #vss# #command handler# #afs# ## #para_server# #para_audiod# #para_audioc# #para_gui# #para_client# ## ## ## ## #The two main applications of the paraslash suite (shaded green) are para_server and para_audiod. Both run in the background usually. para_server maintains the audio file database and acts as the streaming source, while para_audiod is the streaming client. The two client programs, para_client and para_audioc communicate with para_server and para_audiod, respectively. para_gui controls para_server/audiod by executing paraslash commands. Command output is shown in a curses window. para_gui automatically executes para_audioc to obtain the state of para_audiod and para_server and the metadata of the current audio file. Network connections are shaded grey, local connections black.# #para_audiod# #The purpose of para_audiod is to download, decode and play an audio stream received from para_server. It fetches the para_server status and starts a suitable buffer tree (shaded blue) if an audio stream is available. The buffer tree usually consists of a receiver, any number of filters and a writer. The receiver downloads the audio stream from para_server and the filters decode or modify the received data. The writer plays the decoded stream. The dispatcher acts on (local) requests from para_audioc, for example to dump information about the current audio file.# #The audio file selector (afs) accepts two different kinds of incoming connections: A bidirectional pipe shared with para_server is used for passing the file descriptor of the current audio file to the server process. The local socket is used by command handlers which query or update the database. To add a new file to the database, afs opens the file and locates an audio format handler (afh) that recognizes the file. A new database entry with metadata obtained from the afh is then added to the database.# #The audio file selector# #audio files# #para_server# #afh# #osl db# #command handler# #afs# #The OSL database# #Metadata about all known audio files is stored in serveral tables of a database which is driven by libosl, the object storage layer library. The "audio files" table is the main table of the database. It contains path, hash and metadata of each known file. The "attributes" table maps each of the 64 possible attributes to a string. The attribute value of the file's metadata is translated through this table. The tables shown shaded are blob tables which support add, rm, mv, cat, ls commands. All of these are optional. The "score" table describes the subset of admissible files for the current playlist or mood. This table is created on demand, resides only in memory and is discarded on exit. When the next audio file is to be streamed, the audio file selector gets the entry with the highest score from the "score" table, obtains path, hash, and metadata for this entry from the "audio files" table, opens the path and verifies the hash.# #audio files# #playlists# #images# #attributes# #lyrics# #moods# #score# #dispatcher# #status fetcher# #para_server# #receiver# #filter1# #filter 2# #writer# #para_audioc#