FFT-based Audio Analyzer

[steph_tsf]

When I change "samples" (fft control) from 2048 into something higher (16k and above) - FS hangs (both cases, audio on, audio off). Can someone confirm?

Here is the "flight domain" on my side, with the parameters "LPF Fb Hz" on, Audio on, and Timebase "running" :
Timebase(s) ..... Max FFT length
1.00 ......................16384
0.50 ...................... 4096
0.20 ...................... 4096
0.10 ...................... 2048
This is on a Windows Xp SP3 machine dating back from 2006 equipped with the Intel E2160 (Core2Duo generation) CPU clocked at 1.8 GHz. If I'm exceeding such "flight domain", FS hangs. Actually, if I set Audio off, the "flight domain" gets narrower. Why is that so?

[digitalwhitebyte]

I made ​​some changes to the triggers and switch for the filter.
I fixed the redraw to 25hz.
here I can manage now 16384 samples, with 0.20/0.10 TB computing, quite well.

[tester]

Seems to workswitch here too.

[steph_tsf]

@ DWB : Well, I'm no so positive about the "improvement". Okay, I confirm I now can run a 16384 FFT with the timebase set to 0.20 s, which is a 4x speed increase. On the other hand, there is no fundamental change when exceeding the flight domain. If one exceed the flight domain, the crash is total, and the system freezes. Currently I consider this as a main annoyance, potentially impacting the viability of any Flowstone-based solution.

First, we need to determine why the system is freezing, for eradicating such bad behaviour. This is about usability and robustness.

Instead of pushing the performance, I would like to improve the robustness. Later on, when the FFT-based Audio Analyzer gets robust, wel'll have a lot of fun pushing the performance as high as possible using elaborate trigger schemes, using a better Green/Ruby balance concerning the GUI, and converting a maximum of things into Green code.

Last but not least, you introduced a dog somewhere, as now, when the .fsm is idling (audio not enabled, and Timebase off), the CPU drain is 20%. This is not normal.

By the way I don't see how and where the redraw gets limited to 25 Hz. Actually such limitation is not required, as most of the time the timebase is set to 0.10 s or 0.20 s corresponding to a 10 Hz and 5 Hz required refresh rate.

Surely I'll investigate what's going on, learning how to deal with Trigger Galore.

In the meantime I'm posting the .fsm of the former version (that I consider more robust) of the FFT-based Audio Analyzer, dealing with a new D.U.T. consisting of a flexible IIR Lowpass filter implementing Butterworth and Bessel till the 8th-order.

Cheers,
Steph

[digitalwhitebyte]

@ DWB : Well, I'm no so positive about the "improvement". Okay, I confirm I now can run a 16384 FFT with the timebase set to 0.20 s, which is a 4x speed increase. On the other hand, there is no fundamental change when exceeding the flight domain. If one exceed the flight domain, the crash is total, and the system freezes. Currently I consider this as a main annoyance, potentially impacting the viability of any Flowstone-based solution.

This is because when it is activated the audio RubyEdit queues are performed at a higher ratio, based on the sample rate and the buffer of your sound card, so you can be in sync between ruby and soundcard.
will therefore vary from user to user.

First, we need to determine why the system is freezing, for eradicating such bad behaviour. This is about usability and robustness

.

There are several reasons:
the first is that there is a check in the RubyEdit to block it if it exceeds a certain number or computation time, in some cases by putting it in off, or freeze it all up to if he can not.
this mainly in ruby clock used for time base.

others are reviewing the code you use to generate lines etc..
move the part of the calculations that change only if there is an interaction by the user, from the draw method in the methodo event.

eliminate the use of global variables in ruby code that runs in a particular way and are not performing at runtime.

and as already mentioned in my example handle the part of the trig.

Instead of pushing the performance, I would like to improve the robustness. Later on, when the FFT-based Audio Analyzer gets robust, wel'll have a lot of fun pushing the performance as high as possible using elaborate trigger schemes, using a better Green/Ruby balance concerning the GUI, and converting a maximum of things into Green code.

I believe that the Greens are more efficient than the ruby, but still I am not clear what actually happens when the trig comes from a ruby code.
the green will always use the timer windows, both incoming and outgoing?
who has priority on the thread?

Last but not least, you introduced a dog somewhere, as now, when the .fsm is idling (audio not enabled, and Timebase off), the CPU drain is 20%. This is not normal.
By the way I don't see how and where the redraw gets limited to 25 Hz. Actually such limitation is not required, as most of the time the timebase is set to 0.10 s or 0.20 s corresponding to a 10 Hz and 5 Hz required refresh rate.

if you see in my schematic I added a primitive 25tick to redraw,
but I forgot to comment out the line of your code that does the redraw. sorry.
dog? yes the redraw is always performed. even TB off e audo off.

Surely I'll investigate what's going on, learning how to deal with Trigger Galore.

trig the system, has a particular function
trig send value -> to primitive
trig request value <- from primitive attacked
performed every time a trig is on a primitive.

so it is convenient handle and lock these trig, to avoid calculations already performed, and make them run only when all the previous calculation has already been computed

[steph_tsf]

Thank you again MyCo and DWB. After removing the 25 Hz forced redraw I'm perfectly happy. Like DWB wrote, most of the time one can set the timebase to 0.200 s or 0.100 s with FFT lengths equal to 2048 or 4096, knowing that 8192 is also possible on fast PCs. For special cases one can select a slower timebase like 0.500 s coupled to a 16384 or 32768 FFT length. I have a thin doubt about the 65536 FFT length.

Attached is the update.
The .zip contains a full-screen standalone .exe.

Thanks, again
Steph

[tester]

Nice work guys, thank you. I'm curious whether this is the final version (in terms of crucial guts).

[steph_tsf]

At the moment, there are three issues :

1- the program freezes when the user overloads the CPU by selecting a very long FFT combined to a very fast timebase
2- when relying on the internal digital out as reference signal, due to the DAC and ADC latencies there is a delay to be compensated when analyzing an analog device - unfortunately such delay is so long that the built-in cross-correlator doesn' provide valid information
3- the 65536 FFT seems to underperform


I'm going to use the FFT-based Audio Analyzer "as is" in my lab for a while, determining if there are more issues.

One could add features like :
- unrolled phase plot
- group delay plot
- waterfall spectrum
- FFT-based Spectrum Meter modality (no reference channel, hence no phase plot and no impulse response plot)
- processing more than two channels in the FFT-based Spectrum Meter modality
- processing more than one channel, and having more than one reference channel in the FFT-based Audio Analyzer modality
- tutorial explaining the difference between a FFT-based Spectrum Meter, and a FFT-based Audio Analyzer
- instructions for building the special "X" cable that's required for the FFT-based Audio Analyzer, having the Line-out (as generator out) signal feeding the D.U.T. input, also going back into the Left Line-in (as reference signal input), and having the Right Line-in picking up the D.U.T. output.

Cheers,
Steph

[steph_tsf]

Here is a proposal for combining the FFT-based Audio Analyzer and FFT-based Spectrum Meter in one single program.

- It presents as a two-channel FFT-based Spectrum-Meter
- However, one of the two channels gets assigned as reference
- This enables to implement a FFT-based Audio Analyzer on any of the two channels

With the curves colour scheme that's currently in place, there is no way to tell if a curve is from ch1 or ch2. Both magnitudes are blue, both phases are red, and both impulse responses are green.
An alternate curves colour scheme is required. Playing with alpha (transparency) for altering ch2 colours perhaps?

[steph_tsf]

So, here is the FFT-based Spectrum Meter and Audio Analyzer.

This is a four channels instrument. It displays the spectrum magnitudes (blue curves) of four different audio channels, simultaneously.

One channel can be defined as reference channel. The preferred one is channel 1, featuring a variable delay compensation. Up to three audio channels get simultaneously analysed (magnitude in blue, phase in red) basing on the common reference channel. There is a cross-correlator hooked on channel 1 and channel 2, estimating the delay of channel 2 relative to channel 1.

The impulse response (green curve) of one of the three analyzed channels can be graphed. Actually the impulse response of the reference channel can be also graphed (relative to the reference channel), of course this leads to a Dirac pulse.

If you setup all channels as "Spectrum", no reference, and no impulse response, the instrument is easy to use.
Things get a little bit more complicated when configuring one or more channels as "Analyzer". In such case you absolutely need to define a proper reference channel, usually channel 1. This implies that channel 2 and following are connected to the signals you want to analyze.
The impulse response is only available for the channels that got configured as "Analyzer".
Don't be fooled by unerased memory effects like the instrument displaying an impulse response for a channel that got not configured as "Analyzer". I need to improve this, clearing the data and/or issuing a warning. This is in the todo list.

There is no protection against CPU overload. In case the CPU gets overloaded by a long FFT size and/or a fast timebase, the program will freeze. Can Flowstone read the CPU percentage like from the Windows task manager?

Now that the Spectrum Meter modality got implemented, there will be important information showing at the bottom of the graph, like the distortion rays peaks and the noise floor. Unfortunately the Frequency Control surfaces are also at the bottom of the graph. Can Flowstone show/hide the Frequency Control surfaces, using a button? How to program this, in as simple way?

@DWB : the rendering lowpass filter is now 1st order IIR (instead of 2nd order IIR), with special control override concerning the coefficients. This enables implementing a "no filter" configuration, without relying on a dedicated multiplexer/selector.

@MyCo = the Ring Bus that's deployed for F Bus (frequency control) is tricky. Most of the time if you disconnect and reconnect the ring, it doesn't work anymore. One need to be very careful, connecting a F-pad before another F-pad, also connecting the "listener" (the MainView) at a certain stage. Only a few combinations work. Most combinations don't work. When it doesn't work, the Log pad and the Lin pad still control the frequency parameters - you see them changing in the detailed F-pad - unfortunately the "listener" (the mainView) doesn't grab the changes. How to improve this? Is there a connecting sequence to be observed on the Ring Bus?

Cheers,
Steph