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 |
1.1 Purpose2. References
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.3.1 Definitions
1.3.2 Acronyms and Abbreviations
3.1 Module Decomposition4. Dependency Description
3.1.1 Design Class Diagram3.2 Concurrent Process
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.3 Data Decomposition
3.3.1 Data Dictionary3.4 State Model Decomposition
3.3.2 Entity-Relationship Diagram
3.4.1 Connection State Diagram3.5 Use Case Model Decomposition
3.4.2 Explanation of State Transitions
4.1 Intermodule Dependencies5. Interface Description
4.2 Interprocess Dependencies
4.3 Data Dependencies
4.4 State Dependencies
4.5 Layer Dependencies
5.1 Module Interfaces6. Detailed Design for "AUSS"
5.1.1 Connector Interface5.2 Process Interfaces
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.1 AUSS General Protocol
5.2.2 Connector Configuration Protocol
6.1 Connector
6.2 Configurator
6.3 AUSS Lib
6.4 Demuxer
6.5 Muxer
6.6 PipeSplitter
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:
- Provide an easy interface to the soundcard through common methods such as STDOUT as well input sounds through STDIN
- Provide an easy to configure Connector application which provides dynamic connection, multiplexing and de-multiplexing of connections.
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
- Channel – one monaural stream of audio.
- Float – floating point number usually 32-bit in size
- Interleave – mix 1 or more channels of audio together by having each following sample belong to a different channels. E.g. LEFT – RIGHT – LEFT – RIGHT - ..
- Mono / Monaural – Single channel audio.
- Multichannel – Two or more streams of audio like stereo or 5.1. Generally interleaved on output.
- Patch – To connect two units together, much like patch audio cables. Patches provide a transport for audio between units.
- Realtime – A system in which the audio is immediately played to a sound output device at the rate in which it is heard.
- Short – 16 bit Integer number.
- Stereo – Dual channel audio, usually interleaved.
- Frame– 1 fully interleaved sample. In a 5 channel interleaved integer based sound stream a frame consists of 1 sample from all the channels thus 5 integers would make a frame.
- Input Connection– A connection which provides input to a service. E.g. If a white noise generator was connected to connector, it would be an input port.
- Ouput Connection– A connection which provides output from a service. E.g. If connector connected to a soundcard out object, that the sound card out object would be an output port connection.
- Filter Connection– A bi directional connection over sockets which is both an input and output port. E.g. a low pass filter could provide both an input and output interface.
1.3.2 Acronyms and Abbreviations
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.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
State State Explaination "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.1 Intermodule Dependencies
External Library Dependencies: (libraries we did not write)
- Configurator - JDK and Swing.
- Demuxer - AUSS LIB (C/C++)
- Muxer - AUSS LIB (C/C++)
- PipeSplitter - AUSS LIB (C/C++)
- Most of the other modules in the system relies on the POSIX functionality.
4.2 Interprocess Dependencies
Connector relies on Configurator to control the connector. AUSS components4.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.1 Module Interfaces
5.1.1 Connector
5.1.1.1 Connection Interface
Warning Depricated Interface. Please Doxygen generated documentation.
- disconnect() Disconnect Connection from Connector
- getName(): String Get Connections Name sent from Header.
- readable(): booleanCan this connection be read from. Not to be confused with polling for data.
- writable(): booleanCan this connection be written to? Not to be confused with polling for non blocking writes.
- write(data:byte [],size: int)Writes data out to connection.
- read(data:byte [],maxsize: int)Reads data from a connection.
5.1.1.2 FilterConnection Interface
Inherits from Connection. Warning Depricated Interface. Please Doxygen generated documentation.
- connectFrom(conn:Connection) Accepts a connection FROM conn connection. The current filterConnection accepts the connection as an input to the connection.
- process() A step taken which will read in data and output data, fills and dumps one buffer. Must be called to move audio.
- disconnectFrom(conn:Connection) Disconnects an incoming patch between the current connection and "conn" connection.
- disconnectTo(conn:Connection)Disconnects an outgoing patch between current connection and "conn" connection.
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.
- processConnection(connectPntr:int): Connection called to process a new connection. Reads the header and determines the connection type, returns an appropriate connection.
5.1.1.6 ConfigConnection Interface
Inherits from Connection. Warning Depricated Interface. Please Doxygen generated documentation.
- isMessage(): booleanIs there a message from the config connection?
- update()Sends the ConfigConnection a update of current system status.
- getMessage(): MessageGets the current message on the message queue.
5.1.1.7 MessageExecutor Interface
Warning Depricated Interface. Please Doxygen generated documentation.
- executeMessage(msg:Message)Parses and executes the commands in a config message.
5.1.1.8 QuickDirtyXMLParser Interface
Warning Depricated Interface. Please Doxygen generated documentation.
- parseString(str:String): TreeNodeParses an XML string into a set treeNodes.
5.1.1.9 Message Interface
Warning Depricated Interface. Please Doxygen generated documentation.
- getTree(): TreeNodeReturns the root TreeNode of the parsed XML message.
5.1.1.10 TreeNode Interface
Warning Depricated Interface. Please Doxygen generated documentation.
- getChildren(): TreeNode[] returns a list of child nodes.
- getName(): Stringreturns the name of the treeNode
- getValue(): Stringreturn the value of the treeNode
5.1.2 Configurator Interface
5.1.2.1 ViewWindow Interface
Warning Depricated Interface. Please Doxygen generated documentation.
- addViewObject(vo:ViewObject) adds a viewObject to the Window.
- removeViewObject(vo:ViewObject) removes a viewObject from the ViewWindow.
5.1.2.2 ViewObject Interface
Warning Depricated Interface. Please Doxygen generated documentation.
- paintOn(g:Graphics) Object will paint it's self on a graphical context.
- addPropertyChangeListener(pcl:PropertyChangeListener) Adds a propertyChangeListener which will receive events from the object when a state change has occured.
- wasClicked(X:int,Y:int): booleanWas the object clicked if I clicked the mouse at X , Y? Returns a boolean value if (X,Y) is inside the object.
5.1.2.3 ConnectionBox Interface
Inherits from ViewObject Warning Depricated Interface. Please Doxygen generated documentation.
- getName(): String Gets The Connection's Name
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.
- getView(): ViewObject [] get an update from Connector on the state of the system. Return the objects.
- patch(connect1:String,connect2:String)When 2 connections are patched mention the outgoing and incoming connections.
- unPatch(connect1:String,connect2:String) Remove a connection.
- disconnectNode(nodeName:String) Fully Disconnect a Connection.
5.1.3 AUSS Lib Interface
- connect: Connectionconnect to a host or to a pipe and return a connection which will abstract from the developer if they are connected to a pipe or a host. Connect will send the header.
- (host:String,port:int,isConnector:boolean,sendHeader:boolean) For Connecting to a possible nonConnector AUSS Unit.
- (host:String,port:int)Connect to Connector
- (host:String,port:int,type:int)Connect to Connector and specify connection type.
- (pipeName:String)Connect to STDIN/STDOUT/STDERR
- disconnect(conn:Connection)Closes and Disconnect the connection.
- write(conn:Connection,data:byte [],size:int)Write data to the connection.
- read(conn:Connection,data:byte [],size:int)Read data from the connection
- makeHeader(name:String)Makes a proper header to send at the head of the stream.
- mixDown(conns:Connection [],connCount:int, data:byte [],size:int) Takes a list of connections read size bytes from them, mixes the stream to data.
- acceptConnections(port:int): ConnectionAcceptor Binds to a port on the localhost and returns a ConnectionAcceptor
- isConnectionPending(ca:ConnectionAcceptor): boolean Indicates if there is a pending connection.
- getPendingConnection(ca:ConnectionAcceptor): Connection returns a connection from the ConnectionAcceptor from the ConnectionAcceptor.
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
This is the header tag, it encapsulates the header. If the tag isn't used the header will ignored and played.<header><XML/></header>
The name tag informs the accepting program of the identity of the connecting program.<name>Stream Name</name>
- These tags can possibly be ignored but serve for supplying extra meta-information regarding the sound stream.
A non-zero value indicates interleaved stream.<interleaved>0</interleaved>
A non-zero value indicates interleaved stream.<rate>44100</rate>
Indicates how many channels<channels>2</channels>
Either 'big' or 'little' are valid values. Endian denotes the endian of the stream.<endian>little</endian>
Indicates what type of sample. Valid types are 'byte','short','float','double'.<type>short</type>
Indicates the framesize. Sometimes it's easier to send this than to indicate the type of data etc.<framesize>4<framesize>
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:<header> <name>Sample Program</name> <interleaved>1</interleaved> <rate>44100</rate> <channels>2</channels> <endian>little</endian> <type>short</type> <framesize>4<framesize> </header>
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.
H H H H H H D D D D D D D ... D 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>
- Update
- Request:
<request>update</request>- Response:
<update> <connection><!-- per each connection --> <type></type><!-- (INPUT/OUTPUT/FILTER)--> <name></name> <id></id> <framesize></framesize><!-- optional --> </connection> <patch><!-- per each patch --> <from></from><!-- uses ids from to and from --> <to></to> </patch> <time><!-- to compare for updates --> </time> </update>- Patch
- Request:
<patch> <from></from><!-- ids of connection --> <to></to> </patch>
- Response: NONE
- UnPatch
- Request:
<unPatch> <from></from><!-- ids of connection --> <to></to> </unPatch>
- Response: NONE
- disconnect
- Request:
<disconnect> <connection></connection><!-- ids of connection --> </disconnect>
- Response: NONE (Although this should be followed by an update from the client end).
- changedSince
- Request:
<changedSince> <since></since><!-- the time attribute of the last update--> </changedSince>
- Response: Connector is to respond by returning the time of last event which would require a configurator to call update.
<lastChange> <time></time><!-- the time attribute of the connector change--> </lastChange>
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