For the first time I tested the rubber band rubberband pitch shifter Ladspa plugin together with jackd (qjacktl) and jack-rack. I tried both the mono and stereo plugin, but I did leave those two options (first one "Faster") untouched. I used my Electric five-string violin Alien Reiter (from Czechia) for some live test. I had some minimal latency problems (compared to other plugins, but as said "Faster" is untested) else it worked really great! I tested one octave low and high. I have no problems on my AMD Sempron 3600+ based problem but this machine is no good for mobile use (too big mainly).
I also have a MSI wind U100 where I tested tonight some plugins and they needed max. about 20% CPU power without signal stream (this is already somewhat strange). I found out though that the rubberband plugin quickly steps up to 80% and in the next few seconds to 100% and then the qjackctl "RT" shows e+02 or something like that. At this moment the machine is nearly to slow to even move the mouse with touchpad. Any idea why without stream the performance is already this high ?
Is there anything I can do to make this plugin usable on such a machine ? CPU frequency itself is not that slow. I use an external USB soundcard by Roland (Cakewalk UA-1G) and I can usually at least use one plugin with my electric violin without performance problem (5ms latency with that card).
Thanks for the note. This sounds like it may be a floating point denormal problem, particularly given that Intel chips seem to suffer from problems with slow denormal handling much more readily than AMD ones. The commercial builds using IPP have denormals flushed to zero explicitly, but there's currently no such handling in the GPL edition. Will investigate and report back...
Chapter 7-3 ("Thresholding data) explains that so-called threshold functions can be used in this case. I have no idea if these are supported by the gcc compiler. So this is what IPP is about.
The easiest solution would be to simply cut any signal below 200dB (this is probably the root of the problem as I encountered it without any signal i.e. noise). The ardour page explains this in detail:
It states that the gcc option -mfpmath=sse should fix the issue. I wonder if my distributor did activate that option on i586 architecture.
Update: As far as tested no improvement with these optimization flags. Though CPU time might be a bit less (difficult to judge) jack is still at 1e+02 (100 :) % RT. Also CPU performance differs greatlye for 1 octave up and 1 octave down. Even without any changes (everything to 0 and both options off) jack is at 100% RT. I also saw that many xruns are produces (audible) due to that and interestingly if nothing is connected to jack-rack the cpu time is even higher than with the standard noise from the soundcard.
It looks like the best results with GCC will probably be obtained using all of the options: -msse -msse2 -mfpmath=sse -ffast-math -ftree-vectorize.
The first two enable SSE and SSE2 processor units (both are useful for Rubber Band; if your CPU doesn't support SSE2, omit it: you will still gain by using SSE). They just enable the units; the next option tells GCC to use SSE and SSE2 where possible. Then -ffast-math is the option that actually enables the denormal flush mechanism (as well as a few other speed/accuracy tradeoffs that are acceptable for Rubber Band), and the final option is a pure optimisation option that somewhat improves your chances of making effective use of SSE.
If you have a 64-bit CPU, GCC should enable the first three options for you by default, but you should still see substantial benefits from the last two.
Note that pitch shifting upwards uses a lot more CPU than shifting downwards, except in "Faster" mode in which they are approximately equal in CPU but sound quality when shifting upwards is less good.