aubio

Ceci n'est pas un vecteur

For the last few days, I have been scratching my head at this question: should aubio keep using vectors with channels? First of all, the fvec_t structure currently in aubio is a matrix, not a vector, and uses float ** arrays. While it may sound nice to be able to run a phase vocoder or a filter on multiple channels, this leads to several troubles.

Most of the vector functions become ambiguous. For instance, should fvec_min return the minimum value over all channels, or a vector containing the minimum values of each channel? I started using things like fvec_median_channel in the latest branch, but that's really ugly and unclear.

In practice, in aubio we almost always want to mix down to mono before running any algorithm on the signal. All the applications using aubio I heard of were using only one channels. There might be some algorithms where we need multiple channels as input, for instance pan descriptors, but that's a corner case, and using 2 vectors for input is easy.

Now there are some optimisations concerns, as I have measured that running 10 channels in parallel is slightly faster with the current implementation, which allocates the FFT buffer only once for all 10 channels. I got about 3% slowdown when creating 10 times the required objects, instead of using objects with 10 channels ‒ this went down to 2% when running over a ten times longer period, so the performance loss is probably not only due to memory allocation.

Anyway, premature optimisation is the root of all evil.^* So I created a branch, and published it here:

http://bzr.aubio.org/aubio-mono

Unsurprisingly, this makes the code base a little bit shorter (1695 insertions(+), 1800 deletions(-)). Unless someone convinces me there is a very good reason to keep this feature, I will merge the mono branch in the master branch within the next few days.

Thu, 12 Nov 2009, 21:05. trackback - view/add comments

aubio

Ceci n'est pas un vecteur

Responses to this post

Leave your own comment