CSC 499 Term Project
AUSS - Abram's Unix Sound System
Software Requirements Specification
Abram Hindle

Revision Table

Version Primary Author(s) Description of Version Date Completed
1.01 Abram Hindle Cleaning Up SRS Sun Sep 15 18:37:19 PDT 2002
1.0 Abram Hindle Tue Sep 10 22:12:15 PDT 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
1.4 References
1.5 Overview
2. Overall Description
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 User Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communications Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
2.6 Apportioning of Requirements
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Software Product Features
3.2.1 Demuxer
3.2.2 Muxer
3.2.3 Connector
3.2.4 Configurator
3.2.5 Pipe Splitter
3.2.6 AUSS Lib
3.3 Performance Requirements
3.4 Design Constraints
3.5 Software System Attributes
3.5.1 Reliability
3.5.2 Availability
3.5.3 Security
3.5.4 Maintainability
3.5.5 Portability
3.6 Logical Database Requirements
3.7 Other Requirements

1. Introduction

1.1 PURPOSE

This document will server as guide for the design and implementation of Abram's Unix Sound System

1.2 SCOPE

This product is meant for use on one or more computer. It is meant to handle sound in "realtime" as well as "non-realtime". The system will provide tools for the ease of development of sound networks.

1.3 Definitions, Acronyms and Abbreviations

1.3.1 Definitions

1.3.2 Acronyms and Abbreviations

1.4 REFERENCES

1.5 OVERVIEW

Section 2 contains a high level overall description of the product. It contains a general discussion of the interfaces the product will use, and some constraints. Also section 2 contains a description of operations and functions it will perform as well as identifying the users that will use the system.

Section 3 details specific requirements. It discusses external interface requirements, software product features, performance requirements, design constraints, software system details.

2. Overall Description

2.1 PRODUCT PERSPECTIVE

2.1.1 System Interfaces

The system will take advantage of system interfaces to sockets and pipes.

2.1.2 User Interfaces

The configurator will consist of a GUI which enables sound streams to be connected just by dragging and dropping links with a mouse.

Most other systems will use a commandline interface of switches.

2.1.3 Hardware Interfaces

There are no specific hardware interfaces in this project. Hardware control is generally handled by drivers and other sound players for that particular platform.

2.1.4 Software Interfaces

Software interfaces will be made by the system but no explicit external software interface will be in use.

2.1.5 Communications Interfaces

The system is expected to communicate over unix pipes as well as sockets, which are TCP/IP connections over a network; the network could be a lan or the interent. Audio data will be sent raw over these links.

2.1.6 Memory Constraints

The system is expected to use a reasonable amount of memory, a system with 64 mb of ram should be sufficient to run AUSS. The system should take negligible disk space unless audio is being written to disk.

2.1.7 Operations

2.1.8 Site Adaptation Requirements

Not applicable.

2.2 PRODUCT FUNCTIONS

AUSS will provide an easy to use API, who's purpose is to hasten the development of audio applications. AUSS will enable the use of pipes and sockets to move digital audio between processes and computers. AUSS is meant to enable interprocess, intercomputer patching of audio streams. This sort of patching enables software modules to emulate their black box analog equivalent in the analog electronic music systems. The analog systems consist of black boxes linked by patch cables to create a network for the purpose of audio processing. AUSS allows the computer and computer networks to enable this kind of configuration between software processes and computers.

2.3 USER CHARACTERISTICS

Users are expected to be the average unix users who are proficient with the unix commandline environment. Users are expected to have a reasonable understanding of networking and pipes.

2.4 CONSTRAINTS

2.5 ASSUMPTIONS AND DEPENDENCIES

AUSS assumes that loopback networking exists (localhost) on the current machine and the machine is at the very least POSIX compliant (target platform is linux). AUSS assumes all data passing through AUSS is the currently expected and known format declared/known. Some parts of the system will need Java, Perl, C and C++.

2.6 APPORTIONING OF REQUIREMENTS

AUSS will be designed to be maintainable and expandable but current goals are for stability and ease of interface. Maintainability will become more important as the user base grows. Portability will be an issue and Java is being used to provide portability for the GUI.

3. Specific Requirements

3.1 EXTERNAL INTERFACE REQUIREMENTS

3.1.1 User Interfaces

3.1.1.1 Configurator
Configurator will provide a screen which lists all connections to the connector and if they are input connections or output connections.
Input and Output connections will be visible on the screen through named boxes, these boxes will have an input or output hook on can drag from to connect to an opposing box.
Filter Connections have both input and output hooks.
Operations on connections that can be executed are: Multiplexing and demuxing/mixing will be done implicitly through the number of connections. For instance if an input connection gets connected to 2 output connections the input will be multiplexed. If an output connection is connected to by more than 1 input then the streams will be mixed before being sent to the output connection.
3.1.1.2 Connector
The connector will be started from the commandline with configuration information regarding:
3.1.1.3 Muxer
The external Muxer (not muxing inside the connector) will have a commandline interface. The commandline will configure the hosts and ports on those hosts to connect to. Also the commandline will configure where the sound stream is coming from.
3.1.1.4 Demuxer
The Demuxer will have a commandline interface. The commandline will configure the port the demuxer will listen on, as well where the demuxer will output the sound stream to. Commandline will also determine the mixing strategy used as well the type of sound stream.

3.1.2 Hardware Interfaces

Services already provided by operating system.

3.1.3 Software Interfaces

3.1.4 Communications Interfaces

Pipes and sockets will be provided for by operating system.

3.2 SOFTWARE PRODUCT FEATURES

3.2.1 Demuxer

3.2.1.1 Purpose
The Demuxer will accept connections on a TCP port on a computer. Each connection will be expected to send a sound stream, and the demuxer will mix the connected sound streams and output the mixed stream to stdout or out through a socket. If there is no "flow" there will be no sound and nothing will be sent.
3.2.1.2 Stimulus/Response Sequence
N/A - This a commandline oriented application and not interactive.
3.2.1.3 Associated Functional Requirements
  • Mixes incoming sound streams
  • Outputs to mixed stream to stdout or through a socket
  • Listens on a user-defined port
  • Only outputs when recieves input to mix

3.2.2 Muxer

3.2.2.1 Purpose
The Muxer will make connections to multiple hosts. Each connection will be expected to send a copy of the sound stream which originates from stdin or another socket. If there is no "flow" there will be no sound and nothing will be sent.
3.2.2.2 Stimulus/Response Sequence
N/A - This a commandline oriented application and not interactive.
3.2.2.3 Associated Functional Requirements
  • Copies incoming sound stream to outgoing ports
  • Accepts incoming sound streams through stdin or sockets
  • Connects to a list of host/port pairs
  • If one host goes down the others keep working
  • If one host cannot be connected to from the list the other will still be operational
  • Technically doesn't need to know what kind of sound stream it is sending. Potentially any binary data will do.

3.2.3 Connector

3.2.3.1 Purpose
  • To connect audio streams between input connections, output connections and filter connections.
  • To multiplex and demultiplex streams all in one process to improve performance of a complex sound system.
  • To enable realtime reconfiguration of sound streams without restarting processes.
  • To provide a user friendly interface to much of the module configuration.
  • *Possibly* - provide a mechanism to save and load configurations.
3.2.3.2 Stimulus/Response Sequence
N/A - This a commandline oriented application, it is interactive but only provides and software interface and not a user interface. Accepts messages from the configurator or other configuring client and reconfigures connections accordingly.
3.2.3.3 Associated Functional Requirements
3.2.3.3.1 Patching Connections
  • Input Connections - a unidirectional connection which the client provides the sound stream. This connection can be patched to both Output and Filter connections. This connection cannot accept incoming sound streams.
  • Output Connections - a unidirectional connection which the client accepts sound streams. This connection can only be patched to and not from.
  • Filter Connections - a bidirectional connection which client provides and accepts sound streams. This can be patched to and from. Filter Connections can be patched to Output and Input connections at the same time.
Connecting two connections together must be done so on the fly. A drag and release of a mouse is all the effort patching should require so it should be made easy for the software to create sound stream paths between connections. Connections are of similar sound stream types.
3.2.3.3.2 Unpatching Connections
All forms of connections have to allow for unpatching. Unpatching must be able to happen on the fly.
3.2.3.3.3 List Connections And Patches
Clients to connector, connecting for configuration purposes must be able to view what connections exist as well as the patches between the connections
3.2.3.3.4 Terminate Connections
A connection has to be able to be closed. When you are fully done with a connection one must be able to signal to the processes connected to that connection that there is no more work and they should quit.
3.2.3.3.5 Configuration
The Connector system must allow for a "Configurator" or similar client to connect and give configuration commands regarding naming, connections, patching, etc.
3.2.3.3.6 Connection Naming
Connector must allow for a "header" block to name that current connection if it's an input connection. For output connection connector will read the header in (if possible).
3.2.3.3.7 Current Configuration
Connector must allow for configurators to request the current configuration which includes the ports being used.

3.2.4 Configurator

3.2.4.1 Purpose
The configurator is to provide an easy to use interface to the connector. This interface tells the connector how to patch the various connections. Configurator must be told which host and port to connect to.
3.2.4.2 Stimulus/Response Sequence
  • Stimulus:
    • User indicates that two connections should be patched.
  • Response:
    • If the connection is valid (e.g. not input to input or output to output or output to input) a connection is made through the connector and user is visually notified of connection.
    • Otherwise user is notified of inability to patch.

  • Stimulus:
    • User indicates that a patch between to two connections should be disconnected.
  • Response:
    • If a patch between two connections exists, the patch is disconnected and user is visually notified.
    • Otherwise user is notified of inability to disconnect patch.
  • Stimulus:
    • User indicates to close a connection.
  • Response:
    • Connection is closed and removed from list of connections. User is visually notified.

3.2.4.3 Associated Functional Requirements
3.2.4.3.1 List Connections
The system will graphically display connections. Preferably in a way which allow mouse dragging of patches between connections.
3.2.4.3.2 List Patches
The system will display the active patches in the connector.
3.2.4.3.3 Patch Connections
The system will allow the user to request that connections be patched to one another.
3.2.4.3.4 UnPatch Connections
The system will allow the user to request a patch be terminated.
3.2.4.3.5 Disconnect Connections
The system will allow the user to request to disconnect connections.
3.2.4.3.6 Select Connector Host
The system will allow the user to specify which connector the configurator will connect to.

3.2.5 Pipe Splitter

3.2.5.1 Purpose
To provide a utility to split a stereo sound stream onto either STDOUT and STDERR. Each channel of the stereo audio will go to it's own output pipe. This is mainly a utility filter for ease of use.
3.2.5.2 Stimulus/Response Sequence
N/A - This a commandline oriented application and not interactive.
3.2.5.3 Associated Functional Requirements
3.2.5.3.1 Split Audio Streams
Pipe Splitter must split incoming audio streams from STDIN to STDOUT and STDERR. It will assuming interleaving and must be told the format of the audio. No mixing will occur just the splitting of the two streams from the one interleaved stream.

3.2.6 AUSS Lib

3.2.6.1 Purpose
To provide an interface for developers using various languages to easily use AUSS. It will provide wrapper for the network connections that the program would need to make. Overall to make developing AUSS potentially even easier. These functions are mainly for interacting with the Connector.
3.2.6.2 Stimulus/Response Sequence
N/A - This a code library and not interactive.
3.2.6.3 Associated Functional Requirements
3.2.6.3.1 Connecting to Connector
The lib is expected to handle connecting to the connector, generating or passing a connection header and providing a handle back.
3.2.6.3.2 Disconnecting from Connector
The lib is expected to handle disconnecting from connector gracefully.
3.2.6.3.3 Sound Streaming
The lib is expected to provide an interface for easy sound stream in both directions. It is also expected to "block" or buffer when needed. For instance if there is no flow sound streaming should block.
3.2.6.3.4 Header Handling
When connecting to the connector the proper header is sent. The header will be the application name as well as the current sound stream type.

3.3 PERFORMANCE REQUIREMENTS

To improve performance of an AUSS network the connector will be used as the connector is only one process, thus reducing on the amount of context switches needed to move audio around the AUSS network. AUSS aims to be low latency although this isn't totally possible through blocking etc. AUSS relies on the OS to provide reasonable latency. As well since AUSS could potentially be moving megabytes of data per second through pipes and sockets, important components like the connector and the demuxers/muxers should be reasonably efficient at moving data in realtime.

3.4 DESIGN CONSTRAINTS

The following constraints apply to the design of the program:

3.5 SOFTWARE SYSTEM ATTRIBUTES

3.5.1 Reliability

Reliability is important as an unstable system will not be used. The AUSS system is expected to handle most network errors such as not finding a host or losing it's connection gracefully without crashing. Sound maybe stopped but the system shouldn't be unstable.

3.5.2 Availability

Availability should be reasonable but is not an important aspect of AUSS. Basically AUSS should be "available" for a 1 to 3 hour performance.

3.5.3 Security

Security is not a design issue at this time. The system is not designed in a secure manner as services are more client based and somewhat anonymous.

3.5.4 Maintainability

AUSS is meant to be used by other people. These users will have demands and AUSS should be designed reasonably well to handle evolving with these demands.

3.5.5 Portability

Portability is very important to AUSS as it is intended to work on UNIXs and some POSIXs systems. Multi-platform capabilities allow AUSS to have a larger user community therefore Multi-platform is important. Since AUSS can be used in a network fashion this also emphasizes multi-platform support. Support of POSIX libs and Java are expected to help Portability.

3.6 LOGICAL DATABASE REQUIREMENTS

N/A

3.7 OTHER REQUIREMENTS

4. INDEX

Not applicable.

5. APPENDICES