Thoughts on improving performance

[guillaumekh]

libebur128's performance is well suited for live streams, but it can be a bit slow when working with files, especially large ones.

For example, running loudness-scanner w/ TP detection takes about 2 minutes to scan a 2 hours WAV file on my development machine.

Has anyone given some thoughts on how to improve the library's performance?

I have considered the following at this point:

• multithreading: looking at the algorithm's spec (see FIGURE 1, page 3), it seems that at the very least it should be possible to parallelize the first stages on a per-channel basis. I'm also wondering if it would be possible to divide a file into multiple segments, and distribute analysis of those over multiple threads.
• bs1770gain seems to be 3-4 times faster based on testing. I should investigate how they achieve this performance.

It's probably worth noting my employer is open to contracting w/ someone to work on this.

[sdroege]

multithreading: looking at the algorithm's spec (see FIGURE 1, page 3), it seems that at the very least it should be possible to parallelize the first stages on a per-channel basis. I'm also wondering if it would be possible to divide a file into multiple segments, and distribute analysis of those over multiple threads.

We did some experimenting with that in a Rust port of this library. Multi-threading wasn't really worth it there in the bigger picture when doing chunked analysis, see sdroege/ebur128#42 (comment) specifically and the whole PR. There's Rust API now for doing chunked processing from the application side though.

There might be other approaches to multi-threading that are more worthwhile though, or maybe chunked processing speeds up everything considerably for your use-case.

FWIW, the Rust port is slightly faster than the C version by some other optimizations but not 3x-4x faster. How much depends on your setup.

[caustik]

I was able to optimize short-term and momentary full-file analysis by chunking the audio across the number of available threads and then adding some "preroll" aligned to the block boundary for each thread. Of course create unit tests to validate your results are identical to sequential processing. This doesn't handle integrated, but for my particular use case I didn't need that anyway.