Go Down

Topic: Basic software architecture for LED "display" (Read 1 time) previous topic - next topic


, Nyquist says to only sample at 1/2 the frequency

No, Nyquist says to sample at at least half the frequency.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.


Uh, in any case it's the *ambient* music I want to sync the lights with; some of it may be digital, some may not be. It looks as if beat detection is quite difficult to do in software (though there are a couple of simplified hacky versions which get you most of the way there). But putting a low-pass filter on the hardware and then simply watching for when it breaks a threshold might be a goer.

Any commentary on the other part, namely a 60Hz interrupt reading the display values out of a circular buffer? Is that the right approach?

Cheers, Robert.


Most mp3's are sampled at 128kHz,

Slight mix-up of terms here. A commonly used bitrate of mp3 files is 128kbit/s, which means how much compressed data can be used for "describing" one second of music. The more data you can use, the more accurately you can describe the original waveform. That's what makes mp3 "lossy". The audio signal itself is still almost always sampled (and later played back) at 44.1kHz, no matter what bitrate is used for mp3 compression.

But that's,of course, a bit off-topic..

For detecting drum beats, one needs to detect relatively low-frequency transients. So I think there's no need to have very high sampling rates -- high frequency components should likely be filtered out anyway.


Nov 28, 2010, 01:22 am Last Edit: Nov 28, 2010, 01:27 am by focalist Reason: 1
Well, it may help you out to take a look at what I've been working on recently:


It's a realtime spectrum analyzer lightshow jobbie (I use television as output with TVout lib).  The display code you wouldn't need, however, the FFT code would work very well for you.  As written, it does roughly 500Hz bands x 64, so you cover 0-32kHz.  It's very fast and written completely in C (the FFT), and from the forums here.  You'll find code links in the writeup.  This little FFT code is the heart of several little cute projects I'm working on, I'm sure you can find a ton of interesting ways to use it too!

The data you want would most likely sit in that first band, 0-500hz.  

Since the code gives a LOT of usable data out, pick and choose and display how you'd like.. but it at least might take care of the audio processing side of the equation.  Though my current version uses TV as the output, I'm also adding a version which will drive a 16x2 LCD as the graphic output.  It's all a matter of mining the data in the array.  Using the code, you should be able to slice the sound data any way you'd like.  Note that the lib can even perform inverse and real-only transformation also, though I've not come up with a cute way to display that yet...
When the testing is complete there will be... cake.


It does help! I just saw this thread the other day actually, that's pretty awesome. I could be a walking VU meter :-).

How much processor time does the FFT take? If I am only interested in the lowest frequency band, can I do something easy to "optimise away" the rest and save myself some cycles?

Cheers, Robert.

Go Up