Hi folks,
Just an update, ive been following with some interest the evolution of the Rasberry Pi computer concept Raspberry Pi | An ARM GNU/Linux box for $25. Take a byte! Production has just started so my plan is to possibly use one of these little computer per speaker to act as an active crossover using a digital in connection split from my ht receiver and then using the processing power to run active crossovers and possibly some form of DRC signal processing. What do you think? Could it be done or am i asking too much from such a low end processor.
Just an update, ive been following with some interest the evolution of the Rasberry Pi computer concept Raspberry Pi | An ARM GNU/Linux box for $25. Take a byte! Production has just started so my plan is to possibly use one of these little computer per speaker to act as an active crossover using a digital in connection split from my ht receiver and then using the processing power to run active crossovers and possibly some form of DRC signal processing. What do you think? Could it be done or am i asking too much from such a low end processor.
Interesting. If you're willing to have each speaker plugged into the wall (because you will have to have an amplifier in each speaker along with the raspberry pi), you could also have a wireless unit (say bluetooth) so that the speakers don't even need wires. They just talk to a "master" unit that's connected to your audio source.
Its a home cinema still in build stage 6 15" sub 64 mids 200 tweets1080p projector with screen using computer connected Xbox kinect 
to control via voice and motion early days but I will get there. atm the idea of spending £25 per speaker on good quality crossover technology embedded in the stud walls is pretty good compared with the insanity of purchasing something which I don't know and don't trust
to control via voice and motion early days but I will get there. atm the idea of spending £25 per speaker on good quality crossover technology embedded in the stud walls is pretty good compared with the insanity of purchasing something which I don't know and don't trust
You will probably need something like "brutefir" as convolver for doing the active crossover or some kind of drc.
I think if brutefir will be in the repos, it is possible to do some stereo concolving (e.g Roomcorrection) on Rpi.
I am running brutefir (Stereo convolving) on an IBM TP20 PIII@850 Mhz it takes only about 20% of prozessor capacity (TinyCore Linux), so i think (hope) RPi would be strong enough.
I planning to use this little thing for this purpose too...
Regards
sky
I think if brutefir will be in the repos, it is possible to do some stereo concolving (e.g Roomcorrection) on Rpi.
I am running brutefir (Stereo convolving) on an IBM TP20 PIII@850 Mhz it takes only about 20% of prozessor capacity (TinyCore Linux), so i think (hope) RPi would be strong enough.
I planning to use this little thing for this purpose too...
Regards
sky
That's my plan the advantages of such a cheap implementation of active crossovers and the possible power of drc etc could lead to an even cheaper active crossover solution than what is currently available. £25 per speaker for active crossovers sounds pretty good to me. And of course another raspberry used to hold and control all my music or video would be a godsend.
Not necessarily true. BT 2.0 + EDR has a theoretical peak or 2/3Mbps at short ranges. I'm assuming that also includes overhead which is some 30% or so. Most of my lossless music is around 1000-1200kbps, but that is both channels. Assuming you were able to send the channels individually, you should be fine.
That being said, I'd never try it. You are bound to run into issues such as latency differing between the two channels (remember, the transmission isn't real time and as such the latency and bandwidth are not guaranteed). I'm sure I could think of other reasons why BT is a bad idea
it's got to end up costing considerably more than that per speaker. The final digital sound quality is in the dac, so you'll need a good quality dac per driver.
So maybe good value for dsp but only part of total cost
How would you plan on distributing the input data to multiple raspberries which each running independent clocks? I am afraid you would have to use ASRC (e.g. libsamplerate) on the front, e.g. using the jackd2 network plugin. Quality resampling plus quality filtering - I do not know if the ARM CPU of RP (no GPU accelleration) could handle the load..
ATM clocks would be my biggest concern it may be that i actually do analogue digital to analogue conversion but of course time will tell. Early days, I'll know more once I get my hands on a few raspberries.
What is 'analogue digital to analogue conversion'?
Also, how would multiple separate software (or hardware for that matter) ASRCs solve the clock distribution issue either for that matter? If you want master clock sync between the RPi mounted at left/right speakers you'd need to force that issue more directly imo.
Is the clock sync between the DAC for each speaker a big issue? As long as there is a matching amount of audio signal buffered at each localised RPi/DSP module AND you have a properly implemented network with very low packet loss/latency tehn you should negate any time delay between audio from L/R speakers. The phase noise and jitter on the digital signal leaving the RPi for digital to analogue conversion is then mainly dependent on the implementation of audio source/DAC after the RPi surely?
Maybe I'm miles off target but I didn't think that jitter or phase noise of digital signal for left signal relative to data for right signal was critical. In my mind this is a constant time delay that could be fixed simply and also likely totally swamped by room interaction issues.
It's all in theory till we get one in our hands and there are a lot of opportunities we're going to get by having this type of hardware available at such an accessible price point!
Ah ok. I can understand what you're trying to do.
I would look for an adc designed for audio rather than the one onboard the RPi. I am sure the results would be less than satisfactory feeding line out straight into the GPIO port of the RPi.
Honestly the minidsp devices have all of what you're after, already on a single board. To have ADC -> RPi -> DAC and the associated power supplies you'll have a pretty complex system with non trivial amount of work involved in the hardware implementation, before you can even try to set up the software on the RPi.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.