Playing back WMA or MP3 files one sample at a time
JCDammeyer
I'm new to this software and not even sure if this software can do
what I want. I'm the designer of the 2010 Olympic ring lights in
Vancouver, BC. http://www.youtube.com/watch?v=zQkfbiju8CY
A bit of background. There are 742 lights on each side. Works out to
almost 150 lights per ring. Each ring light has 36 LEDs, 9 red, 9
green, 9 blue and 9 white and each group colour in each lamp is
individually addressable. The software (Delphi 2007) runs on a PC and
sends out messages over USB port to a controller board which splits
the lamp intensity messages out to 5 Controller Area Networks (CAN
bus) one for each ring. The colour information is stored in an XML
file and a timer is used to send out the information based on the
duration of each event.
VANOC has run out of money so there's no budget for any more
enhancements or improvements and yet, I'd like to add a music feature
to the project since we did budget for and buy an FM radio
transmitter. Kind of my donation to the Olympic Games.
This Christmas I bought and played with a Light-O-Rama system that can
take an MP3 file and as it plays it out to the audio card, it takes
timed events (also in an XML file) and turns lights on and off.
The key to being able to do this is to decompress the MP3 or XMA into
a buffer and then with a high resolution timer spit it out to the
audio card while comparing the time information with the lamp event
data list. When the time matches an event, set the intensity of a
light or group of lights.
So what I'd like to be able to do is as described above. A simple
function to read in the audio file and at say time 0.10, 0.20, 0.35,
0. 45 etc. seconds write out my USB port the appropriate commands to
control specific lights. Therefore if the main beat of a music file
is 80 beats per minute then every 0.75 seconds I could send out light
control messages.
Currently the Delphi app has a timer which is loaded with the duration
of each event. (we can play shows as seen in the video). When the
timer expires the next event information is sent out to the controller
module and the timer set with the new event timeout. I'd like to
replace this timer with a hires one that sends the sound data out to
the sound card but also checks to see if the timer matches the next
event time. Obviously a multi-threaded app is needed where the hires
timer just sends a signal to the lamp output thread so that the music
can continue without interruptions.
Ideas? Suggestions.
Thanks
John
Martin Michael Kunkies
--
You are recieving this message because you are subscribed to "NewAC users" Google group.
To post message to this group send it to
newac...@googlegroups.com
To unsubscribe from the group send a mail to: newac-users...@googlegroups.com
Additional variants are available at the groups page http://groups.google.com/group/newac-users?hl=en
anb
Well I think solving this task is possible with NewAC.
Since the speed and wxact positioning are the primary concerns I would
recommend using WMA lossless rather than mp3.
Load the file into memory and use the TWMIn and TMemoryStream
components to read it. You can position the file with any precision
you like down to a single sample (by sample I mean the minimum
processable chunk of data, so if you have 16 bit stereo your mimum
sample is 4 bytes). I also recommend using ASIO (TASIOAudioOut) for
output (if you have no ASIO-capable card, it may be software-
emulated). It has the latency of several hundred samples (2-10
milliseconds) while DiretSound latency is above 20 milliseconds.
Timmer
Are you after a relatively simple "color organ" effect, or do you want
to design a light show that steps with each beat?
For the former, you can simply use bandpass filters ahead of level
metering components. Send the instantaneous level information to each
bank of colors (bass frequency to red, mids to green, highs to blue
for example). This method is adaptable to any music, on-the-fly.
A true light show gets a bit more complex. Essentially, you need to
listen to the music and decide where each "step" will be. You'll need
to create a timing map much like you already have, but synchronized to
the start of the music. Then, for each step, set the intensities for
each color and each channel. Very time consuming, but certainly a
more interesting effect.
Taking it to the next level, you can do the stepping on-the-fly by
using, again, a metering component after a low-pass filter (something
like 20 Hz to 300 Hz). This will auto-detect the beats within the
music (the beat is nearly always in the low frequencies) and step
through a preset lighting routine loop.
Under separate email I've sent you a Simple Color Organ demo program
that came with a set of software tools similar to NewAC.
anb
> For the former, you can simply use bandpass filters ahead of level
> metering components. Send the instantaneous level information to each
> bank of colors (bass frequency to red, mids to green, highs to blue
> for example). This method is adaptable to any music, on-the-fly.
>
Isn't it easier to take some short-pointed FFT, like I do in the
TSpectrumIndicator? FFT computation overhead is quite insignificant in
the modern system and you get both bands separation and the level
metering at the same step.
Timmer
The (SwiftSoft) demo that I emailed to John actually uses an FFT.
TSpectrumIndicator would be perfect for this application.
I'll forward the same email to you.
Jim Taylor
Would it be possible for me to see that demo as well? I have an application
where I need to detect certain notes within an mp3 and I think your demo
might help me.
Thank you in advance.
Best,
Jim Taylor
j...@jimtaylor.com
I agree, Andrei.
--
John Dammeyer
> John,
>
> Are you after a relatively simple "color organ" effect, or do you want
> to design a light show that steps with each beat?
Not a colour organ but light show with events on each beat or even between
major beats just like I can create with my Light-O-Rama software.
> A true light show gets a bit more complex. Essentially, you need to
> listen to the music and decide where each "step" will be. You'll need
> to create a timing map much like you already have, but synchronized to
> the start of the music. Then, for each step, set the intensities for
> each color and each channel. Very time consuming, but certainly a
> more interesting effect.
I can use the light-o-rama software to do this. It creates an XML file
that I can parse and turn into an event file for my application. Here's a
fragment.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<sequence saveFileVersion="7" createdAt="12/18/2009 1:05:59 AM"
musicAlbum="Unknown Album (06/12/2009 12:14:01 PM)" musicFilename="Brand
New Day.mp3" musicTitle="Brand New Day">
<channels>
<channel name="Unit 01.1" color="12615744"
centiseconds="21239" deviceType="LOR" unit="1" circuit="9" savedIndex="0">
<effect type="intensity" startCentisecond="0"
endCentisecond="484" startIntensity="0" endIntensity="100"/>
<effect type="intensity" startCentisecond="484"
endCentisecond="494" intensity="100"/>
<effect type="intensity" startCentisecond="511"
endCentisecond="521" intensity="100"/>
It plays out as follows as the music plays at time 0, it lights up circuit
9 from 0 to 4.84 seconds with an increasing brightness from 0 to 100%
Assuming a refresh rate of 0.04 seconds (25Hz) that's 0.8% of total
intensity every step. From 4.84 sec. to 4.94 seconds the lights are on at
full intensity. Then they go off until 5.11 seconds and stay on til 5.21
seconds.
You can see that as long as I can create a data structure list with the
correct granularity, I can sync it with the music. However, with 742
addressable lights each with 4 channels, the complexity is huge so I'd
probably address lights in groups of 5 giving me 30 lights with only 3
colours and manufacture white from the RGB rather than using the white
LEDs.
> Under separate email I've sent you a Simple Color Organ demo program
> that came with a set of software tools similar to NewAC.
Nice simple app. Thanks. Obviously my first step is to make a simple app
that just reads a wav file and sends it out in small blocks to the audio
device. If I can do that in 0.1 second intervals I can probably marry
that to my lamp control stream.
Thanks
John
Timmer
If you use linear PCM audio files (assuming 44.1 kHz sample rate,
stereo, 16 bit), you'll have a BYTE rate of 176,400 8-bit bytes PER
SECOND. To get a timing granularity of 100 milliseconds you need a
buffer size that will present you with a buffer request 10 x per
second, or 17,640 bytes per buffer. I would recommend using something
like 4 buffers, each 17,400 bytes in size.
Your maximum number of lighting control channels (2,968) seems like it
would overwhelm a single control bus, but if you were able to break
that up into 4 quadrants, each with only 742 channels (using 4 USB-to-
CANBUS adapters) it seems like it should be manageable. I'd hate to
see you sacrifice resolution. A 2048-point (or larger) FFT could be
used to generate a real-time audio display of very high resolution, or
you could use 742 channels of a 1024-point FFT and just duplicate the
data to the 4 CANBUS channels.
Send each buffer to your audio output device as well as the FFT at the
same time to keep all in sync. The FFT delay along with the audio
output buffering should result in sync within a 50 mS or less.
None of this should be too much processing for a modern CPU.
John Dammeyer
> Your maximum number of lighting control channels (2,968) seems like it
> would overwhelm a single control bus, but if you were able to break
> that up into 4 quadrants, each with only 742 channels (using 4 USB-to-
> CANBUS adapters) it seems like it should be manageable.
Yes. We discovered that when a third party started doing light shows that
the approach we had taken was way too slow. OTOH, the original project
definition never called for the type of light shows that we're now being
asked to provide.
Our USB interface is an FTDI USB245 which is a serial to parallel USB
interface. However, for ease of debugging during initial development I
chose to use an ASCII protocol and we went with a simple COM port emulator
so we could what was sent out via Hyperterm. This was the right decision
at the time since the entire project from start to unveiling was done in 3
months (made worse by Christmas and New Years Breaks).
However, now I'd rather switch over to the Binary protocol which can be
done very quickly with USB 2.0 in 64 Byte Blocks. That would speed things
up tremendously.
> None of this should be too much processing for a modern CPU.
Yes. But alas the bottle neck is the Freescale 9S12 which takes in the
messages from the PC, has to fill up the image of the ring lights and also
update them every 40mS.
Ideally I'd like to use 5 of the 9S12's, once for each ring, on their own
USB interface running perhaps the DMX-512A protocol. Then theoretically I
could run the LOR software directly. By the time I get this all done the
Olympics would be over....