openAFE, a C++ library for rosAFE¶

Demos¶

openAFE contains a demo binary per processor type. The source code of these examples can be found in the examples folder of the repository. Each binary takes a .mat file as input, which must contains an matrix earSignals of size M samples x 2 corresponding to the binaural input signal, and a scallar fsHz corresponding to the sampling frequency. In the same vein, the binary create a .mat file as well as output. This file contains the data in two separate matrices (left and right channels), and a value called fsHz which is the sampling frequency.

For each demo, you should provide at least the following arguments:

• inFilePath: the path of the input .mat file
• outputName : the name of the output .mat file (including the .mat extension)
• All other arguments (parameters of the processors) are optional. If missing, default values will be used.

Importantly, all the processors that have to be created to compute the requested audio representation are initialized with their default parameters. As an example, the following code can be used to test the gammatone filterbank processor directy from a terminal:

$ DEMO_filterbank inFilePath outputName fb_lowFreqHz fb_highFreqHz fb_nERBs fb_nChannels fb_nGamma fb_bwERBs

where the arguments are:

• fb_lowFreqHz: lowest center frequency
• fb_highFreqHz: highest center frequency
• fb_nERBs: distance between neighboring filters in ERBs
• fb_nChannels: channels center frequencies (Hz)
• fb_nGamma: gammatone rising slope order
• fb_bwERBs: bandwidth of the filters in ERBs

You can notice that these arguments are identical to those of the Matlab Auditory front-end. This will be the case for all the processors implemented in openAFE (see below).

Data exchange between processors¶

The tree workflow has been implemented through an object oriented description, providing general methods to access data from a parent processor, process it, and release it to its child(ren). Basically, each processor instantiation contains a pointer to his parent(s), but does not include any information about his own child(ren). Therefore, the data flow between two processors are handled by two general methods:

• processChunk(), which gets data from the parent processor and process it. Once the representation is obtained, the result is stored on a private internal memory zone (the attributes leftPMZ and rightPMZ), ready to be used by its child(ren);
• Then, releaseChunk() can be used to search for the last chunk of data available in this private memory zone, and to append it to the output signal of the processor.

Such an approach avoids each child of a processor to make a local copy of their parent output(s), which then shares a read access to its own output. This way, the shared resource is not replicated for each child(ren), thus limiting the memory needs.

Processor classes description¶

Multiple classes have been used to describe all processors. On the top of all representations is the openAFE::Processor class, which describes the general common properties and methods of all processors. This includes the aforementioned chunk processing methods processChunk() and releaseChunk(), but also attributes like the name of the processor, its sampling frequency, its input and output size, etc. On this basis, three classes are inheriting this description, each of them being dedicated to time- based, frequency-based and lag-based processors. This is to put in parallel to the three aforementionned signal classes openAFE::TimeDomainSignal (1D signals), openAFE::TimeFrequencySignal (2D signals) and openAFE::CorrelationSignal (3D signals). Each of them gives rise to specific processor classes, which actually implements the processors representation (see the inheritance diagram Fig. 9). For now, the 7 available processors are listed in Table 5.

Fig. 9 Inheritance diagram for the openAFE::Processor class.

Processor parameters¶

All the processor parameters, which all appear as attributes of their corresponding classes, are absolutely identical to the genuine Matlab processor implementation (see here for a comprehensive list).

Note that any change in a processor parameter may require some preparation before being actually used in the processing: for instance, changing the cut- off-frequency of a filter yields to the re-initialization of this filter. This preparation must be explicitly called after a change of parameter through the corresponding prepareForProcessing() method. Note also that each parameter is coupled with corresponding set() and get() methods, which allow to respectively set or read the parameter value of the instantiated processor. Except the blacklisted parameters listed in the original AFE, all the parameters can be modified at any time, thus allowing top-down feedback from higher levels of the Two!Ears architecture. The new parameters are immediately used for the new chunks arriving just after the modification.