CSC 499 Project
Abram's Unix Sound System (AUSS) Program
Software Design Document


Revision Table

1.04 Abram Hindle Deprication of parts of the document Mon Dec 16 23:07:23 PST 2002
1.03 Abram Hindle Finishing Up Some Protocol Definitions Sun Sep 29 12:47:15 PDT 2002
1.02 Abram Hindle Added State Diagram, Filled out more method descriptions Sat Sep 28 14:23:36 PDT 2002
1.0 Abram Hindle Started Wed Sep 18 19:44:24 EDT 2002

Contents

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.3.1 Definitions
1.3.2 Acronyms and Abbreviations
2. References

3. Decomposition Description

3.1 Module Decomposition
3.1.1 Design Class Diagram
3.1.2 Module Descriptions
3.1.2.1 Connector Description
3.1.2.2 Configurator Description
3.1.2.3 Demuxer Description
3.1.2.4 Muxer Description
3.1.2.5 AUSS Lib Description
3.1.2.6 Pipe Splitter Description
3.2 Concurrent Process
3.3 Data Decomposition
3.3.1 Data Dictionary
3.3.2 Entity-Relationship Diagram
3.4 State Model Decomposition
3.4.1 Connection State Diagram
3.4.2 Explanation of State Transitions
3.5 Use Case Model Decomposition
4. Dependency Description
4.1 Intermodule Dependencies
4.2 Interprocess Dependencies
4.3 Data Dependencies
4.4 State Dependencies
4.5 Layer Dependencies
5. Interface Description
5.1 Module Interfaces
5.1.1 Connector Interface
5.1.2 Configurator Interface
5.1.3 AUSS Lib Interface
5.1.4 Demuxer Interface
5.1.5 Muxer Interface
5.1.6 PipeSplitter Interface
5.2 Process Interfaces
5.2.1 AUSS General Protocol
5.2.2 Connector Configuration Protocol
6. Detailed Design for "AUSS"
6.1 Connector
6.2 Configurator
6.3 AUSS Lib
6.4 Demuxer
6.5 Muxer
6.6 PipeSplitter

1. Introduction

1.1 Purpose

This document focuses on the design of the AUSS, including what programming languages will be used, the client GUI, the AUSS API and Connector API. This document provides a design for the AUSS Software Requirements Specification and is written using the IEEE-1016-1989 SDD template. The intended audience are the "AUSS" software developers, Dr. Daniel German, and any programmer who will need to maintain the software in the future.

The goals of AUSS are:

1.2 Scope

The scope of this document is a detailed design of components of AUSS such as Configurator and Connector. The system is meant to be implemented using gcc 2.9.96+,java (1.3.1+) and perl(5.6.0+).

1.3 Definitions, Acronyms and Abbreviations

1.3.1 Definitions

1.3.2 Acronyms and Abbreviations

2. References

3. Decomposition Description

AUSS system consists of:

3.1 Module Decomposition

3.1.1 Design Class Diagram

These Diagrams now serve as rough guides to how the system is designed. They are no longer up to date.
Design Class Diagram Design Class Diagram

3.1.2 Module Descriptions

3.1.2.1 Connector Description
The connector is the workhorse of AUSS, it enables more processes to be used in a AUSS w/o much latency cost because the Connector does so much work in Demuxing and Muxing and routing in one process. Connector routes and moves audio between processes which write audio streams, read audio streams or both. The connector also enables dynamic routing of audio streams between processes.
3.1.2.2 Configurator Description
The configurator is to provide a GUI to configure the connector. The configurator allows users to patch connections together dynamically.
3.1.2.3 Demuxer Description
The Demuxer accepts connections on a TCP port on a computer. Each connection will is expected to send a sound stream, and the demuxer will mix the connected sound streams. The mixed stream will be outputted to either stdout or out through a socket.
3.1.2.4 Muxer Description
The Muxer takes an input stream and copies this stream to a list of host/port pairs computer. The input stream comes from either stdin or a socket.
3.1.2.5 AUSS Lib Description
AUSS Lib is a library which provides and abstraction for connecting to other AUSS components and the AUSS Connector.
3.1.2.6 Pipe Splitter Description
The Pipe Splitter splits an stereo audio stream from stdin into 2 streams outputted on stdout and stderr.

3.2 Concurrent Process

Configurator and Connector will be concurrent processes. Most programs in an AUSS network will be running concurrently. Concurrency is handled by the operating system since each module is a separate process. Connector will have to deal with synchronization of reading and writing to pipes and sockets.

3.3 Data Decomposition

These are mainly Database centric parts of the document so they are not done because we are not using a database.

3.3.1 Data Dictionary

3.3.2 Entity-Relationship Diagram

3.4 State Model Decomposition

State is AUSS is mostly in a connections current state as the whole system is connection based.

3.4.1 Connection State Diagram

3.4.2 Explanation of State Transitions

StateStateExplaination
"connect to host" --"send header" Connection Identifies itself with a header
"connect to host" --"read audio" Connection is an Output connection, it takes audio from the connector, this is based on the port connected to the connector.
"connect to host" --"write audio" Connection is an Input connection, it provides audio to the connector, this is based on the port connected to the connector.
"connect to host" --"read/write audio" Connection is an Filter connection, it takes and provides audio to and from connector, this is based on the port connected to the connector.
"send header" --"read audio" Connection is an Output connection, it takes audio from the connector, this is based on the port connected to the connector.
"send header" --"write audio" Connection is an Input connection, it provides audio to the connector, this is based on the port connected to the connector.
"send header" --"read/write audio" Connection is an Filter connection, it takes and provides audio to and from connector, this is based on the port connected to the connector.
"read audio" --"read audio" Loop of Reading audio from the connection.
"write audio" --"write audio" Loop of writing audio to the connection.
"read/write audio" --"read/write audio" Loop of Reading and writing audio from and to the connection.
"read audio" --"disconnect" Either side of the connection terminates connection.
"write audio" --"disconnect" Either side of the connection terminates connection.
"read/write audio" --"disconnect" Either side of the connection terminates connection.
"disconnect" --"connection closed" Connection is fully closed.

3.5 Use Case Model Decomposition

Use cases aren't very applicable in this situation therefore I withdraw from making any.

4. Dependency Description

4.1 Intermodule Dependencies

External Library Dependencies: (libraries we did not write)

4.2 Interprocess Dependencies

Connector relies on Configurator to control the connector. AUSS components

4.3 Data Dependencies

Data structures of data moving between classes is predefined by the classes.

4.4 State Dependencies

To read or write audio you must be connected to connector or a AUSS program but you don't need to send the header. A output connection is not going to read data from a connection.

4.5 Layer Dependencies

4.5.1 Configurator

The GUI layer depends on the network layer to execute commands inside connector and to connect to connector.

The rest of the AUSS system is not designed in a layered fashion. Potentially The Configurator and Connector Are two separate layer to the same application.

5. Interface Description

5.1 Module Interfaces

5.1.1 Connector

5.1.1.1 Connection Interface

Warning Depricated Interface. Please Doxygen generated documentation.

5.1.1.2 FilterConnection Interface

Inherits from Connection. Warning Depricated Interface. Please Doxygen generated documentation.

5.1.1.3 InputConnection Interface

Inherits from FilterConnection. Warning Depricated Interface. Please Doxygen generated documentation.

5.1.1.4 OutputConnection Interface

Inherits from FilterConnection. Warning Depricated Interface. Please Doxygen generated documentation.

5.1.1.5 ConnectioFactory Interface

Warning Depricated Interface. Please Doxygen generated documentation.

5.1.1.6 ConfigConnection Interface

Inherits from Connection. Warning Depricated Interface. Please Doxygen generated documentation.

5.1.1.7 MessageExecutor Interface

Warning Depricated Interface. Please Doxygen generated documentation.

5.1.1.8 QuickDirtyXMLParser Interface

Warning Depricated Interface. Please Doxygen generated documentation.

5.1.1.9 Message Interface

Warning Depricated Interface. Please Doxygen generated documentation.

5.1.1.10 TreeNode Interface

Warning Depricated Interface. Please Doxygen generated documentation.

5.1.2 Configurator Interface

5.1.2.1 ViewWindow Interface

Warning Depricated Interface. Please Doxygen generated documentation.

5.1.2.2 ViewObject Interface

Warning Depricated Interface. Please Doxygen generated documentation.

5.1.2.3 ConnectionBox Interface

Inherits from ViewObject Warning Depricated Interface. Please Doxygen generated documentation.

5.1.2.4 PatchLine Interface

Inherits from ViewObject Warning Depricated Interface. Please Doxygen generated documentation.

5.1.2.5 Network Handler Interface

Warning Depricated Interface. Please Doxygen generated documentation.

5.1.3 AUSS Lib Interface

5.1.4 Demuxer Interface

Demuxer will accepts connections on a certain port a output them to either another port or pipe. AUSS Lib provides the functionality that the demuxer requires.
This program is expected to be very simple by using AUSS lib therefore it doesn't have a real interface expect from the commandline Warning Depricated Interface. Please Doxygen generated documentation.

5.1.5 Muxer Interface

Muxer creates connections to other host/port pairs and streams input received from either another port or pipe. AUSS Lib provides the functionality that the demuxer requires.
This program is expected to be very simple by using AUSS lib therefore it doesn't have a real interface expect from the commandline Warning Depricated Interface. Please Doxygen generated documentation.

5.1.6 PipeSplitter Interface

PipeSplitter uses AUSS LIB to accept an incoming interleaved stream from a connection and splits it out to two or more other connections (1 connection per channel).
This program is expected to be very simple by using AUSS lib therefore it doesn't have a real interface expect from the commandline Warning Depricated Interface. Please Doxygen generated documentation.

5.2 Process Interfaces

5.2.1 AUSS General Protocol

AUSS uses a raw sound format. That is once headers are passed the rest of the stream is raw audio bytes. Audio can single channel or interleaved multichannel. Each sample can range from the size of a byte to even a double. In this release Short Integers are mainly supported.

The headersize MUST be a multiple of the frame size (sample_size*channels). This is because some AUSS programs might not support the header and they will just play it as if it were audio so it must be of the same frame size otherwise the frames will be out of line which will alter how the audio plays.

The header is in XML (UTF-8) Format:

A Sample header would be

	<header>
	<name>Sample Program</name>
	<interleaved>1</interleaved>
	<rate>44100</rate>
	<channels>2</channels>
	<endian>little</endian>
	<type>short</type>
	<framesize>4<framesize>
	</header>
And the total size would be padded such that the is divisible by 4. Padding is best done in the whitespace before </header>. Each block equals 4 bytes. H = Header, D = Data, A session to connector would look like this:
HHHHHHDDDDDDD...D
After the header is sent each frame is streamed consecutively. A stream might block to determine the speed of the flow. A CD Quality stream will require around 170KB/s, so essentially with a 1 second buffer the stream will block at 170KB fill.

AUSS allows the transmission of any sound type although the muxing for that sound type might not be supported. (Current Plans are for short ints).

5.2.2 Connector Configuration Protocol

The connector configuration protocol uses XML to communicate commands and responses back and forth. The philosophy behind this protocol is that the client requests what it wants, the server doesn't have to tell it. The protocol is described by inferred example. Leading and trailing spaces will be ignored.
If there is an error for any request a message can be sent back which looks like:
 <error>Error Message</error> 

6. Detailed Design for AUSS

Note: If there is more than one Input line for a method, then this implies that the method is overloaded where each line is the parameter list. Warning Depricated Interfaces. Please Doxygen generated documentation.

6.1 Connector

6.1.1 Connection

The Connection is the main interface in the Connector.

6.1.1.1 Methods

6.1.1.1.1 disconnect
  • Public
  • Input:
  • Output:
  • This will close the underlying connection safely as well as disconnect the connector from any patches if nessecary
6.1.1.1.2 getName
  • Public
  • Input:
  • Output: String, the Name of the connection.
  • The name of connection will be passed on by the connection through the header block.
6.1.1.1.3 readable
  • Public
  • Input:
  • Output: boolean, indication of this link will provide a sound stream.
  • This is not for polling. If readable is true, it means the current connection provides a sound stream.
6.1.1.1.4 writable
  • Public
  • Input:
  • Output: boolean, indication of this link will receive a sound stream.
  • This is not for polling. If writable is true, it means the current connection accepts a sound stream.
6.1.1.1.5 write
  • Public
  • Input: data: byte [], size: int , data is the data block and size is the size of the data block.
  • Output:
  • This will write to a connection a data block to an output connection.
6.1.1.1.6 read
  • Public
  • Input: data: byte [], size: int , data is the data buffer and size is the size of the buffer.
  • Output: - through "data"
  • Read will read "size" bytes from the connection and load the data in to "data". Read will only read from readable connection like filters and input connections.

6.1.2 FilterConnection

A FilterConnection implements Connection. As well, FilterConnection is an implementation of Connection which accepts and input and an output stream on one socket.

6.1.2.1 Methods

6.1.2.1.1 connectFrom
  • Public
  • Input: conn:Connection, conn is an "input connection" and provides a sound stream for the current connection.
  • Output:
  • This patches the connection conn to the current connection. It basically adds the connection to a list, then on a process path the output from conn connection will be demultiplexed with the output of other patched connections.
6.1.2.1.2 process
  • Public
  • Input:
  • Output:
  • Process will read and demultiplex incoming audio streams from incoming patches, then it will output outgoing sound streams from the process. Per each call of process() one buffer worth of audio is demultiplexed in and one buffer of output audio is output.
6.1.2.1.3 disconnectFrom
  • Public
  • Input: conn:Connection, "conn" is the connection which is providing an audio stream.
  • Output:
  • Disconnects an incoming patch between the current connection and "conn" connection. The conn connection is incoming.
6.1.2.1.4 disconnectTo
  • Public
  • Input: conn:Connection, "conn" is the connection which is receiving an audio stream.
  • Output:
  • Disconnects an outgoing patch between the current connection and "conn" connection. The conn connection is outgoing.

6.1.3 OutputConnection

Inherits functionality from filter Connection but is not readable, Output Connection can still provide a header but sound streams are not readable.

6.1.3.1 Methods

6.1.4 InputConnection

Inherits functionality from filter Connection but is not writable, Input Connection provides a header for it's sound stream sound streams but is not writable.

6.1.4.1 Methods

6.1.5 ConnectionFactory

The connection factory mediates between the bound ports and the rest of the connector system. The connection factory creates connection objects.

6.1.5.1 Methods

6.1.5.1.1 processConnection
  • Public
  • Input: connectPntr:int , a pointer to the connected socket.
  • Output: Connection - a connection processed from the socket.
  • When a new connection occurs this method is called. It is responsible for initally reading the header and determining the connection type. Once the connection is established and communication has started the method will routine the appropriately made connection.

6.1.6 ConfigConnection

Inherits from Connection. ConfigConnection is a connection which doesn't provide a sound stream, it provides a bidirectional link to a configurator. The configurator and connector speak over this link with XML encoded messages.

6.1.6.1 Methods

6.1.6.1.1 isMessage
  • Public
  • Input:
  • Output: boolean
  • IsMessage returns and indication of if there are are any messages left in the message queue of the ConfigConnection. IsMessage can be polled.
6.1.6.1.2 update
  • Public
  • Input:
  • Output:
  • update sends the current status of the system to the configConnection. The status consists of existing links, existing connections and possibly some configuration information.
6.1.6.1.3 getMessage
  • Public
  • Input:
  • Ouput: Message
  • Pops the oldest message off the message queue.

6.1.7 MessageExecutor

6.1.7.1 Methods

6.1.7.1.1 executeMessage
  • Public
  • Input: msg:Message
  • Output:
  • MessageExecutor will call upon the XML Parser to parse the message into treeNode structure. The message executor will recognize the various messages sent by the configurator and execute them. Message Includes:
    • Patch Connections
    • Unpatch Connections
    • Disconnect Connections
    • Update - get the current status of the system.

6.1.8 QuickDirtyXMLParser

The quick dirty XML parser is just meant to read XML and break it down into tree nodes. None of the complex features of XML will be supported. Only simple structures such as headers need to be decoded.

6.1.8.1 Methods

6.1.8.1.1 parseString
  • Public
  • Input: str:String, str is a XML encoded string.
  • Output: TreeNode, A parsed tree derived from the XML.
  • parseString transforms an XML encoded string into tree like structure consisting of treeNodes. The treeNode can then be interpretted by the msgExecutor to execute actions.

6.1.9 Message

A message consists of the xml string that made it as well as a root treenode to hold the parsed xml tree.

6.1.9.1 Methods

6.1.9.1.1 getTree
  • Public
  • Input:
  • Output: TreeNode
  • Returns the root TreeNode of the message.

6.1.10 TreeNode

A node which consists of a name value and a list of child nodes. TreeNode is used for XML Parsing output.

6.1.10.1 Methods

6.1.10.1.1 getChildren
  • Public
  • Input:
  • Output: TreeNode []
  • Returns a list of child nodes.
6.1.10.1.2 getName
  • Public
  • Input:
  • Output: String
  • Returns the name of the treeNode
6.1.10.1.3 getValue
  • Public
  • Input:
  • Output: String
  • Returns the value of the treeNode

6.2 Configurator

6.2.1 ViewObject

A View Object is meant to be drawn on a ViewWindow. Basically this will be a widget for a ViewWindow. Most likely it will take advantage of 2D drawing calls to draw it's widgets.

6.2.1.1 Methods

6.2.1.1.1 paintOn

  • Public
  • Input: g:Graphics
  • Output:
  • This will paint the object on the current graphical context.

6.2.1.1.2 wasClicked

  • Public
  • Input: X:int, Y:int
  • Output: boolean
  • Based on the X, Y coordinates was this object clicked on?

6.2.1.1.3 addPropertyChangeListener

  • Public
  • Input: pcl:PropertyChangeListener
  • Output:
  • Adds a propertyChangeListener which will listen for various events on the object specifically when object state has changed.

6.2.2 ViewWindow

The view window is a canvas in which viewObjects are drawn upon.

6.2.2.1 Methods

6.2.2.1.1 addViewObject

  • Public
  • Input: vo:ViewObject
  • Output:
  • This method will add "vo" ViewObject to the Window. It will also place the object somewhere in the window.

6.2.2.1.2 removeViewObject

  • Public
  • Input: vo:ViewObject
  • Output:
  • This method will remove "vo" ViewObject from the Window.

6.2.3 ConnectionBox

The connection box is a viewObject which represents the connections inside the connector. The connection box will probably look like a box with text inside of it and nodes on each end, the left end being input and right end being output.

6.2.3.1 Methods

6.2.3.1.1 getName

  • Public
  • Input:
  • Output: String
  • Returns the connection Name.
  • 6.2.4 PatchLine

    Patchline is a viewobject and is simply a line between nodes on patchboxes. PatchLines don't have to be straight.

    6.2.4.1 Methods

    6.2.5 NetworkHandler

    The NetworkHandler handles both the network messages as well as message construction and message parsing. It will send events to the GUI to draw as well as accepts commands from the GUI layer.

    6.2.5.1 Methods

    6.2.5.1.1 getView

    • Public
    • Input:
    • Output: ViewObject []
    • Gets an update from Connector on the state of the system. ViewObject[] will contain all the ConnectionBoxes and PatchLines nessecary display the system state. Also connection types and connection names will be sent.

    6.2.5.1.2 patch

    • Public
    • Input:connect1:String,connect2:String
    • Output:
    • Sends Connector a message to patch the connection represented by "connect1" to the connection represented by "connect2". "connect1" serves as an Input Connection while connect2 serves as an Output Connection.

    6.2.5.1.2 unPatch

    • Public
    • Input: connect1:String,connect2:String)
    • Output:
    • Unpatches and patch between connections "connect1" and "connect2"

    6.2.5.1.2 disconnectNode

    • Public
    • Input: nodeName:String
    • Output:
    • Fully Disconnect a Connection.

    6.3 AUSS Lib

    AUSS Lib is a general library one can use to set up a connection. You can also set information to be passed on to the connector regarding the framesize, channels, sample size etc.

    6.3.1 Methods

    6.3.1.1 connect

    • Input: (host:String,port:int,isConnector:boolean,sendHeader:boolean,type:int) - Connect to "host" using the port "port", if it is a connector "isConnector" is true, and if a header is to be sent "sendHeader" is true. "type" indicates (input/output/filter) connection type.
    • Input: (host:String,port:int,type:int) - Connect to a Connector at "host" with port "port". "type" indicates (input/output/filter) connection type.
    • Input: (host:String,port:int,type:int) - Connect to Connector and specify connection type (INPUT/OUPUT/FILTER)
    • Input: (pipeName:String) - Connect to STDIN/STDOUT/STDERR, type is implied
    • Output: connection
    • Connect to a host or to a pipe and return a connection which will provide an abstraction for the developer if they are connected to a pipe or a host. Connect will send the header. For Connecting to a possible nonConnector AUSS Unit.

    6.3.1.2 disconnect

    • Input: conn:Connection
    • Output:
    • Closes and Disconnects the connection.

    6.3.1.3 write

    • Input: conn:Connectionmdata:byte [],size:int
    • Output:
    • Write data to the connection "conn" of "size" bytes.

    6.3.1.3 read

    • Input: conn:Connection,data:byte [],size:int
    • Output:
    • Read data from the connection into "data" of size "size".

    6.3.1.4 makeHeader

    • Input: name:String
    • Output:
    • Makes a proper header to send at the head of the stream. Names the stream "name". This is called by connect.

    6.3.1.5 mixDown

    • Input: conns:Connection [],connCount:int, data:byte [], size:int
    • Output:
    • Takes a list of connections read size bytes from them, mixes the stream to data. (conns[0][n] + ... cons[connCount-1][n])/connCount = data[n]

    6.3.1.6 acceptConnections

    • Input: port:int
    • Output: ConnectionAcceptor
    • Binds to a port on the localhost and returns a ConnectionAcceptor. The ConnectionAcceptor will be used to accept connections on this port. If NULL is returned there was an error.

    6.3.1.7 isConnectionPending

    • Input: ca:ConnectionAcceptor
    • Output:boolean Indicates if there is a pending connection on "ca".

    6.3.1.8 getPendingConnection

    • Input: ca:ConnectionAcceptor
    • Output: Connection Returns a connection from the ConnectionAcceptor if there is one pending otherwise blocks.

    6.4 Demuxer

    Demuxer relies on AUSS LIB for most of it's methods.

    6.4.1 Methods

    6.5 Muxer

    Muxer relies on AUSS LIB for most of it's methods.

    6.5.1 Methods

    6.6 PipeSplitter

    Pipesplitter relies on AUSS LIB for most of it's methods.

    6.6.1 Methods