-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Desktop Recorder
- Thread starter Pachuquin
- Start date
- Similar Threads Similar Threads
I am using the device recorder.dll, and it works great.
As said before, it records WAV files in PCM, stereo, 11025 samples/sec/channel.
BTW, I use this to develop an audible tachometer, by using fast fourier transformation on a short recording, neglecting the 44 byte header of the WAV file.
But I can't seem to get this pachRecorderDesktop library to record WAV files on the desktop to work. My desktop PC doesn't seem to record or save any file when i try this. Did anybody got it working ? Just to know if the mistake is mine or not.
A very, very basic, working example program of just a few lines to record a file would be very nice, just to see if I do nothing wrong. Sometimes, you start doubting at yourself...
As said before, it records WAV files in PCM, stereo, 11025 samples/sec/channel.
BTW, I use this to develop an audible tachometer, by using fast fourier transformation on a short recording, neglecting the 44 byte header of the WAV file.
But I can't seem to get this pachRecorderDesktop library to record WAV files on the desktop to work. My desktop PC doesn't seem to record or save any file when i try this. Did anybody got it working ? Just to know if the mistake is mine or not.
A very, very basic, working example program of just a few lines to record a file would be very nice, just to see if I do nothing wrong. Sometimes, you start doubting at yourself...
Last edited:
Not using this library (which didn't exist then) - check this http://www.b4x.com/forum/share-your-creations/1938-player-recorder.html#post10505
Thanks a lot Pachuquin, that is most friendly, I appreciate a lot.
I compiled the small program, and tried it on 2 different PC's, one running Win XP SP3 and one running Win7 64 bit Pro. But no success. I can hardly imagine doing anything wrong, it's just too simple. The program seems to react normally when starting the recording, but when hitting the stop/save button, there is this windows sound, warning that the action can not be executed. And no wav file is found :-(
Could it be that I forgot something obvious, or any other tips ? It would'nt be possible to post your executable file, so I could simply check if it runs here ?
I compiled the small program, and tried it on 2 different PC's, one running Win XP SP3 and one running Win7 64 bit Pro. But no success. I can hardly imagine doing anything wrong, it's just too simple. The program seems to react normally when starting the recording, but when hitting the stop/save button, there is this windows sound, warning that the action can not be executed. And no wav file is found :-(
Could it be that I forgot something obvious, or any other tips ? It would'nt be possible to post your executable file, so I could simply check if it runs here ?
OK, this is gonna sound weird:
1) your exe file runs fine, just great ! Thanks for convincing me again there was a problem at my side. Great job, BTW, making that patched libary.
2) i compiled that very simple file myself, but still no results :-(
3) i started triple checking that i had the latest files/libraries everywhere on my PC, removing the library and objects in the IDE, and putting them back in again, recompiling again, and so on...
4) did'nt work at first.
5) at last, I must have done something right, still don't know what it is though, but it works like a charm now. I work on a NAS, changed some settings, started playing with security settings in Win7, and some other stuff, and at once it worked. Can't really explain and it annoys me, I'm sorry.
I feel a bit ashamed, like a real newbie. Anyway, thank you a lot, you made my day !
Edit: a closer look to the resulting WAV learns that it is a mono file that is made on the desktop, instead of the stereo file that was produced before on the device. I don't mind at all, it suits me well, but I thought I would let you know.
And there is an error CS0246 now when trying to compile the same code for a device ? Something about a missing assembly instruction or namespace ?
1) your exe file runs fine, just great ! Thanks for convincing me again there was a problem at my side. Great job, BTW, making that patched libary.
2) i compiled that very simple file myself, but still no results :-(
3) i started triple checking that i had the latest files/libraries everywhere on my PC, removing the library and objects in the IDE, and putting them back in again, recompiling again, and so on...
4) did'nt work at first.
5) at last, I must have done something right, still don't know what it is though, but it works like a charm now. I work on a NAS, changed some settings, started playing with security settings in Win7, and some other stuff, and at once it worked. Can't really explain and it annoys me, I'm sorry.
I feel a bit ashamed, like a real newbie. Anyway, thank you a lot, you made my day !
Edit: a closer look to the resulting WAV learns that it is a mono file that is made on the desktop, instead of the stereo file that was produced before on the device. I don't mind at all, it suits me well, but I thought I would let you know.
And there is an error CS0246 now when trying to compile the same code for a device ? Something about a missing assembly instruction or namespace ?
Last edited:
I found a way around the error message:
I compiled the code for the desktop as stated above, with your patched library. Everything fine there.
But before trying to compile for the device, remove that patched library for the desktop, and replace it with the normal dummy library "RecorderDesktop.dll". Compile as usual for the device, and you're OK.
I don't know why this influences the device compilation, but it works.
BTW, this is in no way criticism, I'm very happy it works ! Just trying to help.
And of course, on the device you keep getting a stereo file as before. This can be seen in the file length (compared to the duration of the sound), and also in the header of the wave-file: 22050 bytes/second.
I compiled the code for the desktop as stated above, with your patched library. Everything fine there.
But before trying to compile for the device, remove that patched library for the desktop, and replace it with the normal dummy library "RecorderDesktop.dll". Compile as usual for the device, and you're OK.
I don't know why this influences the device compilation, but it works.
BTW, this is in no way criticism, I'm very happy it works ! Just trying to help.
And of course, on the device you keep getting a stereo file as before. This can be seen in the file length (compared to the duration of the sound), and also in the header of the wave-file: 22050 bytes/second.
Because the compiler assumes that the desktop and device libraries are identically structured and uses the objects, methods and properties of the desktop library when compiling for both the device and the desktop. This is why you need a dummy desktop library equivalent to compile for a device library that only works on a device.
Last edited:
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 ?
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 ?
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.
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")
Last edited:
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 ?
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 ?
Last edited:
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.
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.
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
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 ! :wav:
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 ! :wav: