Notice! This is not the actual class documentation. This page is a collection of design notes and thoughts. I've noticed that by trying to write a good class description (roles, interface, use), you quickly find out about possible desing flaws.

• 1. Class descriptions
  • 1.1 General classes
    • 1.1.1. CHAIN
    • 1.1.2. ECA_PROCESSOR - eca-main.{cpp,h}
    • 1.1.3. ECAPARAMS
    • 1.1.4. ECARESOURCES
    • 1.1.5. SAMPLE_BUFFER - samplebuffer.{cpp,h}
  • 1.2 Audio IO-Devices
    • 1.2.1. AUDIO_IO_DEVICE
    • 1.2.2. CDRFILE
    • 1.2.3. ECASYNTH
    • 1.2.4. EWFFILE
    • 1.2.5. MP3FILE
    • 1.2.6. NULLFILE
    • 1.2.7. OSSDEVICE
    • 1.2.8. OSSDMA
    • 1.2.9. OSSDEVICE
    • 1.2.10. WAVEFILE
• 2. Concepts
• 3. Signal flow
• 4. Performance

1. Class descriptions

1.1 General classes

1.1.1 CHAIN

A CHAIN represents a single signal flow abstraction. Every CHAIN has one slot for an audio input device and one slot for output. Because these device objects are unique and can be assigned to multiple chains, id numbers are used to refer to the actual device objects. In addition, CHAIN has a name, a SAMPLE_BUFFER object and a vector of CHAINOPs which operate on the sample data.

1.1.2 ECA_PROCESSOR - eca-main.{cpp,h}

This class is the actual processing engine. It is initialized with a pointer to an ECAPARAMS object, which has all information needed at runtime. Processing is started with a start command and after that, ECA_PROCESSOR runs on its own. If the interactive mode is enabled in ECAPARAMS, ECA_PROCESSOR can be controlled from other threads. The simplest way is to use the COMMAND_QUEUE class. It offers a thread-safe way to transmit command strings. ECA_PROCESSOR creates one COMMAND_QUEUE object and reacts to all commands sent to this queue. This should be used when the command isn't used continuously. The other way to communicate with ECA_PROCESSOR is to access the ECAPARAMS object directly. For this to work, mutex locking must be used. This for instance makes possible to monitor signal volume level in realtime.

1.1.3 ECAPARAMS

1.1.4 SAMPLE_BUFFER - samplebuffer.{cpp,h}

Basic unit for representing sample data. The data type used to represent a single sample, value range, channel count, sampling rate and system endianess are all specified in "samplebuffer.h".

1.2 Audio IO-Devices

1.2.1 AUDIO_IO_DEVICE

AUDIO_IO_DEVICE is a virtual base class for all audio io-devices. Audio devices can be opened in the following modes: read, write or read_write. Input and output routines take pointers to SAMPLE_BUFFER objects as their arguments. All devices are either non-realtime (normal files) or realtime (soundcards). Realtime means that once device is started, data input/output doesn't depend on calls to AUDIO_IO_DEVICE object. With non-realtime devices, input and output is done only when requested. Due to performance issues, much of the responsibility is given to the user of these classes. It's not impossible to write to an object opened for reading (probably with disastrous results).

1.2.1 AUDIO_IO_DEVICE

1.2.2 CDRFILE

1.2.3 ECASYNTH

1.2.4 EWFFILE

1.2.5 MP3FILE

1.2.6 NULLFILE - audioio.{cpp,h}

1.2.7 OSSDEVICE

1.2.8 OSSDMA

1.2.9 OSSDEVICE

1.2.10 WAVEFILE