Using Propeller as a Sound Processor
carline
Posts: 13
Can someone point me to information about using the Prop as a sound processor.
I am currently using the Prop Demo Board and love it.
I want to sample input audio, i.e.· detect frequencies and drive·multiple pins/·LEDs with·individual/separate
frequencies somewhat like a VU meter. I'm not very experienced with code yet but I'm working on it.
I know this sounds a lot like a color organ and that I could just buy/build one dirt cheap but this seems much more
interesting! I've tinkered with some of the posts that have preset patterns but thought that the audio combined
would be fun to build. Hope to use this to drive some light displays to keep some grandchildren happly. Thanks for
any and all help
Chuck·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chuck Arline
·
I am currently using the Prop Demo Board and love it.
I want to sample input audio, i.e.· detect frequencies and drive·multiple pins/·LEDs with·individual/separate
frequencies somewhat like a VU meter. I'm not very experienced with code yet but I'm working on it.
I know this sounds a lot like a color organ and that I could just buy/build one dirt cheap but this seems much more
interesting! I've tinkered with some of the posts that have preset patterns but thought that the audio combined
would be fun to build. Hope to use this to drive some light displays to keep some grandchildren happly. Thanks for
any and all help
Chuck·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chuck Arline
·
Comments
Don't know how much you know about the maths of digital signal processing, basically when you sample you get what's known as a "time series" because the samples are spaced equally in time. To get frequency data you need to transform it, usually done in computing with an FFT but that's really heavy computing.
I suspect that a lot of the frequency channel VU meters of old used analogue filters to select the frequency component (can't think of a cheaper way to do it in a consumer Hi-Fi for example).
However, some time back this interesting project was done by a Parallax Engineer:
http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=204569
Take a look at that, if you can figure it out you might be able to change it from a graph on screen to an LED matrix of some sort. I've not looked at the code, probably quite optimised.
Of course if you just want a single bar graph volume display, you just need to get a magnitude and convert that into a number of LEDs to light.
I have (or used to have) an FFT equalizer program for the TandyRadioShack-80 Color Computer in the 1980s.
As of today I think I have an "Easy Fourier Series". I have to clean it up and prove it though.
I'm not sure it is efficient like an FFT but I think it's a clever method and hope it's good. THIS ISN'T IT!
I'm disappointed that the FFTs I've found on here are either so uncommented that I can't use them,
and one that was called a spectrum analyzer was very slow.
I have FFT source code for an old 1 MIPS PIC16C54 but it is likewise uncommented.
If that and the TRS-80 can do it... or in any case I have no doubts that the Propeller can be used
as a frequency domain filter, processor, or synthesizer.
Many apps have come up for Fourier Analysis but FFT is still a box of dark magic for most of us;
simple but beyond the comprehension of mortal minds.
Someone could use it for speech recognition, recently discussed.
I'm hoping my EFS algorithm will be useful, considering that it's a different solution.
It has no multiplication like FFTs.
I hope it can be simplified further as a "Fast EFS",
but if it has the nature of a slow DFT
then at least I think I was tricky enough so that it might work with unexpected speed.
THE SLOW FT IS SIMPLE BUT IT IS DEFINITELY SLOW:
1.get some samples at least at 8000 sps rate, the higher the better until 44100 sps or more.
2.multiply (oh no!) each sample by a sine wave of a frequency and store it in another array vector
3.multiply each sample by a cosine wave and store it in a third array vector
4.add together all the numbers obtained in step 2 and divide by number of samples
5.add together all the numbers obtained in step 3 and divide by number of samples
6.use pythagorean theorem to get the volume of the frequency: vol_freq(f)=square root(step4 x step4 + step5 x step5)
6-B. or you can be cheesy and just say vol_freq(f)=step4+step5
7.repeat for each frequency you want to know and store them in an array vector for each frequency
7-B.If you are making a VU meter for an equalizer then find out how to convert the array to dB and do that
(My guess is use the spin >| operator to get a log2)
8.Display the results (although for testing and debugging you could do this between steps 6 and 7).
Slightly hard parts:
Making the right sine wave for each frequency. You have to figure out which sine wave frequency fits
in all your samples first and then which harmonic (multiple) of that frequency is the one you want.
At 8000 sps, and 8000 samples that would be simply the frequency you want, so "somehow" make
that many sine and cosine waves to multiply in steps 2 and 3. Somehow means you have to do
some math. If you had a 8000 point sine wave in an array, multiply the pointer by your frequency
and then use the remainder after dividing by 8000 to get a new pointer that makes your frequency,
which is how many sinewaves you will be multiplying your samples by.
The above paragraph WILL NOT WORK that easy, if you are making an equalizer. First, it will be
very slow, and even if it weren't slow, it would still be CORRECT as it graphs only once per second.
Instead, you need enough samples for 40 milliseconds, because that's how human beings hear both
frequency and time (which don't even coexist in reality... you are only either surfing on windy soundwaves
or hearing one eternal chord in reality). At 40 milliseconds, one 25 Hz sinewave fits, so you will have to
divide your frequency by 25 to get the number of sinewaves of your frequency that fit in your samples.
Remember this is the slow way that is easiest to understand. It might not be fast enough to make
an equalizer. The FFT does this my magic, using less adding and MUCH LESS multiplying, but without
a sense of what should be multiplied when. (Oh No!) I say because the Propeller doesn't multiply as
fast as it adds, and any multiplying would have to be done in PASM. (The whole Fourier transform
must be done in PASM if at all).
Ok, regardless of what transform, slow, fast, or easy, you did, now the filtering part.
If you just wanted to make an equalizer screen you can loop back to step 1 now.
After the filtering part, where you multiply by how much of each frequency you want to come out...
And while the Fourier Transform is working on the next batch of samples...
The inverse transform is easy.
Your vectors contain the Volume of each sine and cosine frequency you measured times how much of them
you want to make... because Volume controls work by multiplying the sound by how much of it you want.
Now remake each Sample: by adding all of the sine and cosine waves of frequencies you want together, AFTER
A. multiply a "sample" of each sine and cosine by the volume of it (Fourier Transform Volume x Volume Control)
which you stored in your vector.
B. add together all the pieces of those sinewaves
C. you now have an equalized sample to output. It's going to be at best case 40 milliseconds delayed,
definitely worse. It needs to go out as fast as it came in. To avoid skipping, you probably need a first-in-first-out
array/vector/buffer (synonyms?).
D.repeat when the next Fourier Transform is done and go to step A. This must be happening in another cog.
If it works, you've got an equalizer!
Some of the shared vectors used by Transform Cog and Inverse Transform (synthesis) Cog must be in Hub,
which can be a headache some times. Beware of Synthesizing in the same vectors that the Transform is
doing it's math in. What a Mess!!! Not so bad if you can do an FFT and an IFFT though because it uses only one vector.
Whatever magic is used, this is the trick the Fourier Transform does:
It multiplies at least a sinewave (should also do cosinewave) of a Frequency by some samples, and adds them all up,
and ignore any minus signs in the sum.
It does that by any way that works, for each frequency that fits all of it's sine waves in the samples.
DFTs are a Convolution trick that avoids Convolution needing information from the future since sines are always
the same as they were in the past. The delay may be how the rule is enforced.
Convolution of voice with instruments sounds interesting but demands
playing one or the other backwards if the DFT isn't used. The analog way is to just run a hose of instrument sound
into your mouth from a muffed amp, and then sing without using your voice into a microphone (Talk Box).
I think Peter Frampton is famous for doing that.
If you have an FFT then you might want to look up hamming, hanning, gaussian, and triangular "windows".
The purpose of them is to smooth out some of the glitches in the DFT.
I think that the FFT is used with window functions only if it is done after each sample, which pushes the FIFO
buffer and the oldest sample falls into the bottomless recycle bin.
DFT means either the SLOW or FAST "Discrete(non continuous sampled) Fourier Transform". They do the same thing.
There are cheesy tricks:
They will distort the sound if you are equalizing so don't unless you want lots of fuzz.
You can use square waves instead of sine waves. Then you don't need to multiply.
You can use triangle waves instead of sine waves. Square is EASY and triangle is not as hard as Sine.
PROPELLER has a sine table, but only one fourth of a wave. You have to figure out how to make the rest,
and how to make the cosine, so I hope you got an A+ on your Trigonometry or Calculus test.
God Bless You if you understand the Fourier Transform with the Sigma e i Pi zero infinity in it and
you can make an equalizer program out of that!
I'm still working on my Easy Fourier Series code, and will be very excited if it actually works.
I'm very eccentric so if you have a nice math professor, forget all my BS and get plenty of extra help after class.
Except for EFS (until it's done) you know all I think I know about Fourier Transform signal processing.
future reference 04551.12345
Check this out from a 16K color TRS-80 in 1981 with only a few 100 KIPS. Propeller must be able to do much better!
www.youtube.com/watch?v=TIOhfHGIjis
I ran that ROMPAK once. Used the cassette port audio. I think it was 6 bits of resolution. BTW: Those things had fast and robust cassette routines built in. File names, and high speed / noise variation tolerances.
Can't remember if the higher speed clock was used, or not. Probably not as it was in the TANDY catalog. I've a CoCo 3, and just found my official Motorola 6809 Programmers Guide. (cool!)
The ROMPAK image of this is online, if it's worth looking 6809 code over for the tricks. Lots of tricks possible on that CPU. Probably the most elegant and powerful 8 bitter made. (ducks from the Z-80 fans) Anyway, it has a hardware multiply. 8x8 = 16 bit result.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I looked a that book mentioned in other threads, on Hartley transforms. Is there a "Transforms for Dummies" ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The graphics mode used was SG24 which had 9 color hi-res wide pixels AND text.
CoCo 3 did not have that graphics mode, since it used a different graphics chip, that had 80 columns text mode
and allowed the the colors to be changed; there was a 16 color palette, I think.
So the program doesn't work on CoCo 3 because the video mode doesn't exist and is wrong by default.
TMI: MC6847 video chip did not have SG24 without the MC6883 SAM which added extra modes,
decoded the memory addresses, and interlaced the ram refresh cycles. SAM also used 65495 to double
the clock,but CoCo 3's chip used 65497 for overclock (which disabled ram refresh on the earlier models).
No software that I recall actually used the double speed, since some of the RAM wasn't fast enough, and
would freeze some machines.
Regardless of whether the program works, a 4K ROM might not be too much to disassemble and reverse engineer.
I have sufficient info about the memory map.
@Toby: the MUL instruction was probably the slowest. 6809 at 0.9 Mhz ... at least 8 cycles for a mul if not double that.
Fourier Transforms are not just for audio. They were originally invented to predict heat dissipation of a
torus shaped radiator or something like that, and in calculus they usually move greek symbols around or
change one formula into another and not as computer algorithms.
en.wikipedia.org/wiki/Fourier_transform
simple.wikipedia.org/wiki/Fourier_transform
I've been as focused as I can be specifically on the audio spectrum analysis applicable algorithms.
The simplest it can be imagined is the "FFT butterfly" flowchart, (showing additions and substractions)
which is the same as for FHT and FWT except for the elusive values for the multiplies often by the W(?) function.
My best understanding is that W(t) means separate multiplications by sin(pi t/ s) , cos(pi t/ s), which
are added together in FHT and not even done in FWT. Use google images and search for "FFT butterfly".
(or "cooley-tukey algorithm"). You might find a BASIC or FORTRAN version, or a recursive C version,
en.literateprograms.org/Cooley-Tukey_FFT_algorithm_(C)
faculty.prairiestate.edu/skifowit/fft/
which may be translated to Spin (but only for testing, needs PASM for real-time audio).
Remember also it doesn't make any sense except when all samples represent approximately 40 milliseconds total.
The number of points (samples) should be minimum 16, optimum is probably 256 or 1024 for audio.
A DIFFERENT BUT SIMILAR FORUM+THREAD : FFT FOR DUMMIES
www.kvraudio.com/forum/viewtopic.php?t=76588
Post Edited (VIRAND) : 11/16/2009 10:44:36 AM GMT