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?

Programs:

• 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.
• AUSSLib C and example, A C API for the AUSSLib.
• AUSSLib Perl and example, A Perl API for the AUSSLib.
• Demuxer, sits on a port and demultiplexes audio data to stdout.
• Muxer, connects to multiple hosts and streams audio data out.
• 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.

Documentation:

• 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 project.
• 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 demuxers.
• Different Mixer Types
• Rename Connections

Regrets

• 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.

Issues

• 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.
• 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 strategy.