Abram Hindle 0020755 Dec 19 2002
- Was the schedule met?
- Yes all milestones were effectively met, some tasks were rearranged and traded between
Milestones but the milestones were met.
- What has changed?
- The User Manual is assumed to be the User Reference. The Developer reference is assumed
to be the design information. The SDD was somewhat abadoned for a reverse engineering
approach using Doxygen.
- What was actually done?
- Connector, a audio routing daemon. The heart of AUSS.
- Configurator, a program which interfaces with and
configures the Connector.
- AUSSLib Java and example, A Java API for the
- AUSSLib C and example, A C API for the AUSSLib.
- AUSSLib Perl and example, A Perl API for the
- Demuxer, sits on a port and demultiplexes audio data
- Muxer, connects to multiple hosts and streams audio
- PipeSplitter, splits interleaved audio to two streams,
outputted on STDOUT and STDERR.
- Sink, connects to the connector and acts as an output
connection, writes data to STDOUT.
- cvolume example, program which acts as a filter
which adjusts the volume of incoming audio.
- javavolume example, program which acts as a filter
which adjusts the volume of incoming audio.
- API Doc, describes AUSS Format and AUSSLib
- Schedule, a draft schedule
of the project.
- Changelog, a log of things I worked on and dates.
- SDD, the first Design Document for AUSS.
- SRS, the first Requirements Document for AUSS.
- The UserManual, for users of AUSS.
- The First Iteration Summary, Summary of tasks
completed during the 1st iteration of AUSS.
- The Proposed Evaluation, how the project will be
marked and the deadlines for Milestones.
- The Inital Proposition, this was the project
advertisement I sent to the prospective supervisors.
- Short Description for the Proforma, describing the
- Configurator Javadoc, The current
structure of the code for the Configurator.
- Connector Doxygen Generated
Docs, the current design documentation revere engineered from Connector
and associated programs.
- AUSSLib Language Specification, API docs for C, Java and Perl.
- What is there left to do?
Things left to do are:
- Network Latency Tests: the network performance of AUSS needs to be tested.
- Latency Tuning: Tuning the buffers used in the sockets (e.g. with ioctl)
- Different Data Types: More complex commandline options are needed for the
Muxer, Demuxer, Sink etc. to allow for different types of data structures as well as
to pass headers identifying these data structures. Data types is one area which is
somewhat implemented but not tested very well.
- MultiPlatform Support: Support for Non-linux systems and use GNU utils to configure
compilation for those systems.
- Audio Testing: It is very hard to automate tests for audio. I would like to see
regression tests put into AUSS because you can't hear some "bugs" but automated
systems could have a chance picking it up.
- What should be done later?
- More Automation: it'd be nice to automate connecting even more
- Device/File Level Muxer and Demuxer: It'd be even easier to use AUSS if instead
of a socket one could just open file or device and read and write data into AUSS
through this interface.
- Experiement with user level threads vs the single threaded approach.
- Text message passing is important. It would be nice have text message muxers and
- Different Mixer Types
- Rename Connections
- The concurrent pipe lines ABAS was not read before designing or implementing the
system. It problably would have resulted in a clearer understanding of the system.
- More thought should've been put into synchronization.
- Possibly a multithreaded design would have been more effective.
- Policies: Policies are need to handle situations like one consumer isn't reading
or behaviours for certain cases.
- Realtime: As previously discussed consumer operating systems are not very
affeulent in realtime computing nor do they care about maintaining very accurate
wait or sleep times. Buffering is probably the only way to overcome the realtime
problem with audio. I personally use Low Latency patches on my kernel to reduce
- Latency: Low latency patches help, but buffering produces latency. Sometimes a
lot of latency. Latency increases as more processes are combined.
- Buffersizes: What size of buffer should one use. Buffering basically needs to be
balanced against performance and latency.
- DataTypes: Datatypes need to be tested properly and thoroughly. Datatypes
include, floats, shorts, big endian, little endian.
- Headers: Sometimes headers aren't sent soon enough thus they are ignored and a
connection is unnamed or improperly configured.
- Consumer vs Producer vs Synchronization: In the case of a Muxer if there are
multiple consumers and some read a lot faster than others sometimes the the slow
consumers miss frames and therefore play the audio a little faster distorting
whatever was being played. This can't really be overcome without a clear policy or