Parallel Reverb Processor

Carl Doersch and Keith Bare

Proposal

Milestone 1

Milestone 2

Final Report

Samples



Parallel Freeverb Code

Milestone 2

April 16, 2008

Major Changes:

Since our last milestone, there have been no changes to the scope of our project; we are still working on a Reverb processor.

Accomplished so far:

Since the last milestone, we have both attained a good understanding of the reverb process and the datastructures that freeverb3 uses.

Given this knowledge, we were able to design and implement a baseline MPI parallel version of freeverb3. On a machine with p processors, the program will break the input sound file up into p chunks and processing each chunk separately. On each processor, the program constructs a "revmodel," which is a sound filter (made up of several comb filters and allpass filters), identical to the one used in the original freeverb3. Passing a series of samples through the revmodel will apply reverb to the samples; hence, each processor passes its samples through its revmodel, and then the samples are assembled back into a full file at the end.

However, this introduces an inaccuracy in the output file. When a processor starts in the middle of a file, it has no information about the previous sound in the file; that previous sound should be generating some background reverberation at this point in the file. In effect, at the boundary between chunks, the output file suddenly, momentarily loses all of its reverberation and sounds like the original, un-reverberated file.

We have a plan to fix this problem, and it's mostly implemented. When each processor finishes processing its chunk, it will pass its revmodel to the processor processing the next chunk in the file, and that processor will will continue feeding samples into the passed revmodel until the passed revmodel's output looks like the processor's own revmodel's output.

Finally, we have some preliminary timing data for the parallel program. The time for actual computation is speeding up nicely; 5.72s on 1 processor, 2.83s on 2 processors, and 1.41s on 4. However, total speedups are poor, due to slow I/O reading and writing of audio files. We're using a 64 Megabyte input file, which contains 6 minutes and 15 seconds of audio. When the input file is cached by the operating system reading takes about 2 seconds. However, writes and reads with a cold buffer cache take about 13-14 seconds.

Meeting The Milestone:

We met our milestone; we have a working parallel program that we can analyze for performance, and we have done a small amount of analysis already.

Surprises:

One surprise that has had minimal effect on our project has been how long compilation takes on the parallel computer systems we have access to. This was most noticable when we had to compile third party code; libsndfile and freeverb itself.

The more important surprise has been the poor I/O performance mentioned above. We can think of a few ways to work around this problem. First, we believe that I/O performance may be greatly improved if we work with files in the /scratch filesystem rather than our home directories. We recall reading a page on the PSC web site mentioning that the network connection providing home directories is not particularly fast. A second strategy is to try parallelizing computation and I/O. By doing this, we'd be able to overlap reading the file with the reverb computation.

Revised Schedule:

The remaining schedule does not need any revision, as we are currently on track.

4/24

Continue experimenting with other algorithms

5/1

Decide which algorithm we will finally use. Finish all coding and testing, and prepare poster.

Resources Needed:

It seems that modern PC's can always process reverb in real-time; hence we'll be focusing on batch processing. Bigben should be enough to accomplish this; although we may run the program on other machines for comparison.