Desktop Recorder

[redbird]

Very logical, thank you Agraham.

I know you did'nt make the patched library for the desktop yourself, but you wouldn't have any clue why it records in mono format, while on the device it always records in stereo format ?
I wonder if there is something in the patched library that changes this ?

[agraham]

There is no relationship between the two libraries. They use entirely different mechanisms to do the recording. The "patched library" isn't patched at all, it is an entirely different desktop-only library written by Pachuquin, hence the library name.

BTW any chance of a look at that interesting sounding FFT app? Do you do the FFT in Basic4ppc code - if so it should speed up a lot, with minor amendments, with the next version of Basic4ppc that supports typed variables.

[redbird]

Originally Posted by agraham

BTW any chance of a look at that interesting sounding FFT app? Do you do the FFT in Basic4ppc code - if so it should speed up a lot, with minor amendments, with the next version of Basic4ppc that supports typed variables.

Sure, it's working well and relibale as a protoype, but it isn't finished yet.
The goal is to record a working radio-controlled heli, and to determine the speed at which the 2 main rotorblades are turning, somewhere between 1000 and 4000 RPM. I use 2^12=4096 bytes of a wave recording for that. I'll post more when it's finished.

But I have terrible performance problems, as you guessed:
On the desktop, the calculations are done in less then a second with a decent PC, but on a HTC Touch HD, it takes well over 2 minutes :-(
I really need to get it down to an acceptable amount of time for the end-user, something like a few seconds or so.

The core of the calculations, the FFT transformation, looks like this:
(the first part, the bit reversal is fast enough, but the second part is very slow). After that, there is some filtering and frequency peak detection to do, but that is the easy part.
Note: rawdata() contains the 4096 byte values from the wave file, rawdataIM() is empty in the beginning.

'THE FAST FOURIER TRANSFORM
'Upon entry, N=4096 contains the number of points in the DFT, rawdata() and
'rawdataIM() contain the real and imaginary parts of the input. Upon return,
'rawdata() and rawdataIM() contain the DFT output. All signals run from 0 to N-1.
NM1 = N-1
ND2 = N/2
M = Round(Log(N)/Log(2))
J = ND2
For i = 1 To (N-2) 'Bit reversal sorting
If i >= J Then Goto bit1
TR = rawdata(J)
TI = rawdataIM(J)
rawdata(J) = rawdata(i)
rawdataIM(J) = rawdataIM(i)
rawdata(i) = TR
rawdataIM(i) = TI
bit1:
K = ND2
bit2:
If K > J Then Goto bit3
J = J-K
K = K/2
Goto bit2
bit3:
J = J+K
Next i

For L = 1 To M 'Loop for each stage
LE = Round(2^L)
LE2 = LE/2
UR = 1
UI = 0
SR = Cos(cPI/LE2) 'Calculate sine & cosine values
SI = -Sin(cPI/LE2)
For J = 1 To LE2 'Loop for each sub DFT
JM1 = J-1
For i = JM1 To NM1 Step LE 'Loop for each butterfly
IP = i + LE2
TR = rawdata(IP)*UR-rawdataIM(IP)*UI 'Butterfly calculation
TI = rawdata(IP)*UI+rawdataIM(IP)* UR
rawdata(IP) = rawdata(i)-TR
rawdataIM(IP) = rawdataIM(i)-TI
rawdata(i) = rawdata(i)+TR
rawdataIM(i) = rawdataIM(i)+TI
Next i
TR = UR
UR = TR*SR-UI*SI
UI = TR*SI+UI*SR
Next J
Next L
Msgbox ("Ending FFT calculations")

[redbird]

By declaring all the arrays as double, instead of single, I reduced the calculation time from about 140 seconds to about roughly 100 seconds.
That is included the filtering and other calculations I did'nt post, but these take like a few percent of all the needed time.
Thanks to the tip in the new book, that I started reading :-)
It is still not fast enough to my liking, if the version 6.90 could improve this bij another 400 - 1000 % as said, that would be very nice though.
This could get the times down to an acceptable level.
BTW, would anybody have any other tips to speed things up ?

[klaus]

Do you have a rawdata example you could post, I would be pleased to make some tests with version 6.9.
Or eventually could you post your test program.

Do you really need 4096 samples ?
Wouldn't 2048 or even 1024 be sufficient?

Best regards.

[mjcoon]

Originally Posted by redbird

BTW, would anybody have any other tips to speed things up ?

I have no idea how efficient array accesss is (especially with explicit integer index values), but historically one would extract an array item into a local variable to work on it if there were going to be several usages at the same index location (as I think you have). You could name the variables as, say, rawdataIMIP to make the correspondence apparent. This may make a difference with the release version of Basic4PPC.

Mike.

[redbird]

Originally Posted by klaus

Do you have a rawdata example you could post, I would be pleased to make some tests with version 6.9.
Or eventually could you post your test program.

Do you really need 4096 samples ?
Wouldn't 2048 or even 1024 be sufficient?

Best regards.

Here is a CSV file, with exactly 4096 bytes, extracted from a WAV file.
These numbers need to be in the array rawdata(0-->4095) of course.
I can't post the test program yet, it's only an undocumented draft, I hope to be able to do it soon.

I tested using 1024 and 256 bytes (should be an even power of 2), but this is not precise enough in the range I'm looking for, and that's around 50-150 Hertz. I only have a 11025 sample/sec rate.
These manual tests were done with the Analysis Toolpak in Excel, and I could double check the results, so I prefer to stay with the 4096 bytes for accurate results.

Thanks in advance.

[agraham]

Try this, it does a 4096 point transform in less than a second on my iPAQ 214. I can't vouch for the accuracy but the code is pretty well unchanged from the original which is based on a well known Java benchmark and round trips pretty accurately. The algorithm is an in-place algorithm and uses a single array. I have added Split and Join methods so you can quickly transform to and from 2 separate arrays.

[redbird]

Originally Posted by agraham

Try this, it does a 4096 point transform in less than a second on my iPAQ 214. I can't vouch for the accuracy but the code is pretty well unchanged from the original which is based on a well known Java benchmark and round trips pretty accurately. The algorithm is an in-place algorithm and uses a single array. I have added Split and Join methods so you can quickly transform to and from 2 separate arrays.

OK, this is EXACTLY what I was looking for, I guess.
A FFT library working in Basic4PPC. I looked on the forum, but saw messages that it didn't exist, so I gave up, and used the slow routine posted above.

First of all: I did a quick compile now, and a testrun on my HTC Touch HD (version 1): even with the time needed to click the message boxes, it took indeed only a few seconds ! So should indeed be like a second or less.

Two: give me some time to try to incorporate this into my actual code, so I will have be able to compare on a fair basis, I will report back to you, I promise. I think I only need to put my real data into the array called "data()". Should be a small job.

Three: if this will work, and I wouldn't dare to doubt you, then you did me an incredible favour. You are the greatest, I read a lot about all your knowledge on this forum, but I wouldn't figure that you would get a working, fast FFT library out of nowhere in the blink of an eye. Thanks again, I mean this.

The tacho tool is supposed to be one of the most essential and difficult parts of the toolkit I'm writing, hence the importance (and my enthusiasm).
And with the recording problems solved now, this was the only thing holding me back.

Best regards,

Raf

[redbird]

Yes, yes and yes again ! This works !
I changed your code to suit me, and added a lot of tables to make things more visible. This makes it very slow now, but it is only for testing, you understand.

I took my 4096 REAL bytes of data in the csv file (these are in fact simply 8 bit amplitudes from a wave-file), loaded them into table1, added the "missing" imaginary numbers (all zeros in my case), and showed this in table2.
From there on, i did the FFT transformation, resulting in table3: 2048 pairs of numbers (real+imag).

After that, I loaded the same csv file in Excel, and did a complete manual FFT calculation, and checked it with table3. Guess what, every single number is correct !

You will find my code and the csv file in attachment, simple load the code in the IDE and run, you'll see what I mean.

Note: in my final program, the raw sound bytes will be loaded directly from the wave-file into the array "rawdata()", this doesn't take much time.

Thank you so much !