Good morning,
I was thinking about using one of those small ARM based boards to use it as a player. Something similar to this project. I was thinking about using a clone of the famous Beagle Board: IGEPv2.
Afterwards, I started about the possibility of running BruteFIR. I spoke with the author about the posibility of optimizing it for ARM, but he is not keen to spend more time on it.
I investigated a little bit further and I found the Hawk Board. It has a floating point DSP running at 300Mhz. It cost around 112$ (74GBP). Looking at the DSP Library Reference Programmer's Reference Guide it is stated the cycles required per operation. For a 48000hz signal it should take around 3 million cycles to perform the FFT convolution (I might be wrong -DSP is far from being my expertise-). So it looks enough to run several filters at the same time.
BruteFIR is amazing, but it looks like it would be enough to develop a JACK client. JACK would provide the infrastructure to do all the connections between filters. In that regard, it looks like it would be a matter of modifying BruteFIR code or jconv just to use Texas Instrument's DSPLIB.
I am not a DSP guy and it is been more than 10 years without developping in C or C++ so I am quite rusty.
Does this look feasible to you guys? Would anybody with much DSP/programming background than myself take over this idea?
Kind regards,
José M.
I was thinking about using one of those small ARM based boards to use it as a player. Something similar to this project. I was thinking about using a clone of the famous Beagle Board: IGEPv2.
Afterwards, I started about the possibility of running BruteFIR. I spoke with the author about the posibility of optimizing it for ARM, but he is not keen to spend more time on it.
I investigated a little bit further and I found the Hawk Board. It has a floating point DSP running at 300Mhz. It cost around 112$ (74GBP). Looking at the DSP Library Reference Programmer's Reference Guide it is stated the cycles required per operation. For a 48000hz signal it should take around 3 million cycles to perform the FFT convolution (I might be wrong -DSP is far from being my expertise-). So it looks enough to run several filters at the same time.
BruteFIR is amazing, but it looks like it would be enough to develop a JACK client. JACK would provide the infrastructure to do all the connections between filters. In that regard, it looks like it would be a matter of modifying BruteFIR code or jconv just to use Texas Instrument's DSPLIB.
I am not a DSP guy and it is been more than 10 years without developping in C or C++ so I am quite rusty.
Does this look feasible to you guys? Would anybody with much DSP/programming background than myself take over this idea?
Kind regards,
José M.
Writing a convolution engine for the C67 isn't all that difficult, especially since it doesn't need to be fully optimized if you're just doing stereo FIR filters. It seems to me that implementing the framework of passing buffers around between ARM and DSP would take considerable low-level coding effort. Last time I checked there isn't much high level code allready doing this available in the hawkboard / beagleboard community so you would be pretty much on your own.
What I would do is look for a nice and small board with a chip with hardware floating point support. You might even investigate if running a beagleboard with software floating point support might deliver enough horsepower for the FIRs you need.
What I would do is look for a nice and small board with a chip with hardware floating point support. You might even investigate if running a beagleboard with software floating point support might deliver enough horsepower for the FIRs you need.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.