<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">The fft is running in floating point precision and is not using any</div>
</div>
hardware acceleration (like SS2). Allowing it to optionally use integer<br>
fft routines (which we do have) could be worth trying. Alternatively<br>
trying to apply ORC optimizations to the butterfly operation of the FFT<br>
library would speed it up.<br>
<br>
Both are not trivial things to do ...<br>
<br>
Stefan<br><br></blockquote><div><div><br></div><div>Thanks for the suggestions, Stefan.</div><div><br></div><div>For interest, here's the result. I was just about able to run the Gstreamer spectrum element on this eleven year-old Compaq Presario 700 as part of a shrimping project, now immortalised in video.</div>
<div><div><a href="https://vimeo.com/44535515">https://vimeo.com/44535515</a></div><div><br></div><div>Unfortunately when I try to launch anything substantial on the machine, like open a browser, the CPU time this takes away from gstreamer somehow causes pulseaudio to halt altogether until I kill the python script which launched the pipeline. Basically once there's an underrun it seems to be terminal.</div>
<div><br></div><div>As I think you guessed, I was looking for a low-effort way to reduce load, so I didn't get into rewriting the core logic of the spectrum element. I was surprised that the CPU load of the FFT doesn't depend on some other factors like the sample rate, which I might be able to reduce cheaply. For now, it works, and that's good enough!</div>
<div><br></div><div>Cefn</div><div><a href="http://cefn.com">http://cefn.com</a></div></div></div></div>