Kevin_Murray said:
watch the good side, in 2 -3 years you can buy the virtex5 for that money
...or not ?
http://www.hpcwire.com/hpc/1195762.html
http://www.lynxone.com/aes16.html
I picked this up for 400 Usd on ebay ( im cheap and have to think bout resale value
) so it has AK4114 's and lots of it . Vista driver is also in the works, but lets wait for SP1 first hehe...
I picked this up for 400 Usd on ebay ( im cheap and have to think bout resale value
) so it has AK4114 's and lots of it . Vista driver is also in the works, but lets wait for SP1 first hehe...
flshzug said:http://www.lynxone.com/aes16.html
I picked this up for 400USD on ebay ( im cheap and have to think bout resale value
What are your plans for this board? Do you have it up and running yet?
Kevin_Murray said:This is what I suspected. Fortunately this project relates to my job so in time it will happen (plus I'm stubborn). Regarding keeping current, I'm finding out just how much has changed since I've been away from DSP. There is some impressive hardware available now, though it's making choosing a platform more difficult
I expect I will be doing nothing but reading through the new year. I hadn't planned on determining a hardware configuration till the end of January. Initially I had planned on just a crossover and maybe delay added in. I think that parameteric eq wouldn't be too hard to integrate with DRC the ultimate goal. I see that some people are interested in 6-8 channel DSP which is a processing nightmare, unless going to multiple hardware paths. Maybe a feature wishlist would help to generate a block diagram which would then help determine hardware requirements?
Food for thought:
http://www.analog.com/processors/sharc/overview/benchmarks/index.html
The ADI SHARC procesors are awesome and ADI has a ton of software libraries abailable such as room correction.
The Sharc has 8 AD8196 ASRC's and SPDIF transceivers on chip. I'm working on a board with 1 Blackfin BF-537 as an ethernet receiver running Linux, SHARC for audio processing, and the AD1955 as the DAC. Eventually I'd like to add additional AD1955's for digital cross-overs using the SHARC.
The Visual DSP 5.0 IDE is available as a 90 day test drive. ADI is very good about adding time to the license for the asking. Visual Audio from ADI does not require an additional license and provides a graphical tool for building DSP code. You can also drive the DSP from the Visual Audio tool in realtime to adjust volume, balance, FIR filters, delays, parameteric eq, etc.
Very complete and pretty cool. I'm looking forward to shifting my DIY activity from hardware to software. Certainly a lot cheaper to play with software!
-David
OzOnE_2k3 said:
As far as reducing the number of ADC/DAC conversions, it should be possible on most devices (DVD players, home theatre receivers, etc) to sneak some wires onto the DACs and peel the signal right off the I2S lines. There would have to be some 'scope time, of course, to suss out the digital format, but nothing insurmountable. There's also a project afoot to build an external AC3 decoder so you can feed its digital output to whatever clever trickery may exist downstream.
Now, about the FIRs: a 50 ms filter sounds like room EQ in the bottom end. You don't need it. Most, if not all, low frequency room problems are quite correctable with IIRs, featuring way less latency, a not-unimportant consideration for watching movies. Shorter FIRs, such as for speaker correction above the bass, would still take a few computrons, but as the posts above mention, bruteFIR and other FFT based solutions require a lot less power than convolution based systems like a canonical FIR. Remember the properties of convolutions: a convolution in the time domain is a multiplication in the frequency domain, and vice-versa.
OzOnE_2k3 said:
We basically need a DSP guru to tell us if this project is achievable without costing more than a Beatles court case!
[...]
Surely there must be many manufacturers missing out on a big market share? I'm sure plenty of people would be interested in a resonably priced DRC solution to add to their home theater / hifi setups?
If you want to roll your own, DRC is way cheaper in DIY than off the shelf. Other people have spoken of SHARC/DAC solutions, and putting those together is _much_ less expensive than dropping a few grand on stereo DRC - let alone the price tag for 5.1.
Manufacturing electronics is a non-trivial task, and you might find Bose (boo, hiss) has surrounded automatic room correction (having the user move a microphone around during setup) with a wall of patents. On the other hand, should you come up with a better way of doing so, then you have the upper hand (after dropping twenty grand on getting a Bose-proof patent).
The retail price of gear needs to be about four to five times the parts cost, because out of that the retailer and the distributor take their cuts, so you're left with 35% of retail if you're lucky. Applying that formula to $2500 of DRC means the parts must be around $500 to $600. Once you've costed out circuit boards, connectors, chassis (really expensive!), and semiconductors, it turns out the silicon is almost the least of your expenses. Everything else really adds up. Conceivably there's a place for 5.1 DRC, so that might be a sweet spot because your infrastructure (chassis, etc) costs are just about the same but you can charge a reasonable price for the system.
Hi Andrea,
I started with the eval boards, and now just in the starting stages of building my own.
Have a look at the linux deployment for the Blackfin. Pretty cool.
http://blackfin.uclinux.org/
ADI Has a great website for the Blackfin. The page has a number of tutorials, codes examples, and beginner's guides to DSP's. Besure to checkout their SDK for use with VisualDSP++.
http://www.analog.com/processors/blackfin/index.html
BTW, thanks flshzug for fixing my part number typo regarding the AD1896 asrc.
-David
I started with the eval boards, and now just in the starting stages of building my own.
Have a look at the linux deployment for the Blackfin. Pretty cool.
http://blackfin.uclinux.org/
ADI Has a great website for the Blackfin. The page has a number of tutorials, codes examples, and beginner's guides to DSP's. Besure to checkout their SDK for use with VisualDSP++.
http://www.analog.com/processors/blackfin/index.html
BTW, thanks flshzug for fixing my part number typo regarding the AD1896 asrc.
-David
I beleive the smaller blackfins are only up to a single task (and in stereo) at a time. For load like FIR you would want the BF561 dual core. And keep in mind the BF is 16 bit integer ( 32 bit with extended prec) wheareas the Sharc excels at floating point. I think you can find heaps of resource for the latter (fp) , music-dsp mailing list comes to my mind.
Hi,
Just an update of where I am atm.... The more I look into doing full DRC using DSP chips, the more I'm realizing how much power is actually needed and how expensive it can get.
I'm now currently laying out a PCB design for a "muxit" type interface which I intend to use on my Audiotrak Prodigy 7.1 card to output the I2S signals directly to my amp's DAC's. This is based on Brian Brown's "muxit" interface.....
http://www.diyaudio.com/forums/showthread.php?threadid=22741
and inspiration from Vil's mod.....
http://www.diyaudio.com/forums/showthread.php?postid=671434#post671434
I understand a lot more about I2S and DAC signals now, but I've never actually played with DACs etc. before. There are a few hurdles to get past, but I've been wanting to build something for ages.
The first problem is how I'm going to implement the I2S receiver mod on the amp (Denon AVC-A11SR).... It looks like the DACs in the amp (AD1854K) are usually fed with 48KHz / 24bit audio, but they can be switched to 96KHz input via a pin controlled by the CPU. It also looks like most audio is converted to 24bit (by the first DSP), so hopefully I can just set the ASRC chips on the "muxit" receiver to 24bit output and work out the rest of the details after.
Another problem is whether or not I would need to isolate the link between the amp and the PC as I know I already get a nasty ground loop between the two (loud buzzing and interference when analog cables are used - one of the main reasons for using an all-digital link in the first place.) Or maybe the LVDS link would be enough isolation anyway (hopefully).
Something else which would need to be added to the muxit receiver board is a multiplexer IC so that the external signal could be switched in and out of the loop. ie. the external input could be switched onto the amp's DACs only when the cable is plugged in AND a specific input is selected......
(On the Denon, this would need to be an input which is set for 6 or 8 channels because the amp mutes the unused channels. It also can't be the "EXT IN" (analog) input, because this input bypasses the DACs altogether.)
Luckily I have the service manual for my amp, but I can see how complex this can get with different amps. What strikes me about this is that you might as well build everything from scratch anyway!
Eventually, I'll look into DSP again, but probably using FPGA chips because it should be possible to create FIR filters by doing very fast parallel calculations inside the chip. It should also be easier to load in new filters etc. In fact, now that I know a little bit more about the FIR calculation, FPGA chips make perfect sense. (Whereas DSP chips are designed for more generic tasks, more of an FPGA's resources could be dedicated to the task of FIR filtering.)
A quick question to the DAC gurus - I'm still unclear on how most DACs handle 16/20/24bit inputs when using I2S.... Does the DAC still "clock in" 24bits when only 16bits are input (missing LSBs are zeroed?), or does the LRCLK denote when the last LSB is input? (ie. does the source only "clock in" 16bits before the LRCLK signal changes?)
Anyway, I'm rambling on as usual. I hope at least one person finds some of this stuff useful as I always tend to write long posts!
OzOnE.
Just an update of where I am atm.... The more I look into doing full DRC using DSP chips, the more I'm realizing how much power is actually needed and how expensive it can get.
I'm now currently laying out a PCB design for a "muxit" type interface which I intend to use on my Audiotrak Prodigy 7.1 card to output the I2S signals directly to my amp's DAC's. This is based on Brian Brown's "muxit" interface.....
http://www.diyaudio.com/forums/showthread.php?threadid=22741
and inspiration from Vil's mod.....
http://www.diyaudio.com/forums/showthread.php?postid=671434#post671434
I understand a lot more about I2S and DAC signals now, but I've never actually played with DACs etc. before. There are a few hurdles to get past, but I've been wanting to build something for ages.
The first problem is how I'm going to implement the I2S receiver mod on the amp (Denon AVC-A11SR).... It looks like the DACs in the amp (AD1854K) are usually fed with 48KHz / 24bit audio, but they can be switched to 96KHz input via a pin controlled by the CPU. It also looks like most audio is converted to 24bit (by the first DSP), so hopefully I can just set the ASRC chips on the "muxit" receiver to 24bit output and work out the rest of the details after.
Another problem is whether or not I would need to isolate the link between the amp and the PC as I know I already get a nasty ground loop between the two (loud buzzing and interference when analog cables are used - one of the main reasons for using an all-digital link in the first place.) Or maybe the LVDS link would be enough isolation anyway (hopefully).
Something else which would need to be added to the muxit receiver board is a multiplexer IC so that the external signal could be switched in and out of the loop. ie. the external input could be switched onto the amp's DACs only when the cable is plugged in AND a specific input is selected......
(On the Denon, this would need to be an input which is set for 6 or 8 channels because the amp mutes the unused channels. It also can't be the "EXT IN" (analog) input, because this input bypasses the DACs altogether.)
Luckily I have the service manual for my amp, but I can see how complex this can get with different amps. What strikes me about this is that you might as well build everything from scratch anyway!
Eventually, I'll look into DSP again, but probably using FPGA chips because it should be possible to create FIR filters by doing very fast parallel calculations inside the chip. It should also be easier to load in new filters etc. In fact, now that I know a little bit more about the FIR calculation, FPGA chips make perfect sense. (Whereas DSP chips are designed for more generic tasks, more of an FPGA's resources could be dedicated to the task of FIR filtering.)
A quick question to the DAC gurus - I'm still unclear on how most DACs handle 16/20/24bit inputs when using I2S.... Does the DAC still "clock in" 24bits when only 16bits are input (missing LSBs are zeroed?), or does the LRCLK denote when the last LSB is input? (ie. does the source only "clock in" 16bits before the LRCLK signal changes?)
Anyway, I'm rambling on as usual. I hope at least one person finds some of this stuff useful as I always tend to write long posts!
OzOnE.
Oh well, nevermind. Just found the Philips I2S spec. (did quite a bit of searching for timing diagrams before, but should have just gone to the source!).....
http://www.nxp.com/acrobat_download/various/I2SBUS.pdf
So, the lower LSB bits are ignored / set to zero when lower bit depths are input to a DAC (eg. 16bits into 24bit DAC). That's good to know, and makes things a lot easier for interfacing etc.
OzOnE.
http://www.nxp.com/acrobat_download/various/I2SBUS.pdf
So, the lower LSB bits are ignored / set to zero when lower bit depths are input to a DAC (eg. 16bits into 24bit DAC). That's good to know, and makes things a lot easier for interfacing etc.
OzOnE.
Just came across this thread and it's muchos interesting. I myself am into DSP and am going to be getting into programming the dual-core SHARC processors in a big way over the next few months.
One point that springs to mind: the Blackfin processor has been mentioned several times. The salient point about the Blackfin is that it's a 16/32-bit processor, with a 16-bit MAC and 40-bit accumulators. It's really designed for doing 16/32-bit calculations, which isn't enough for high-quality audio coming in at 24-bit. The SHARC, on the other hand, has a 32-bit MAC and 80-bit accumulators, which is nigh-on perfect. You could misuse it and do double-precision operations but that's really slow and it's better just to use better hardware. The SHARC does do floating-point, although I wouldn't use 32-bit floating-point for audio (see my other threads for the reasons why). 40-bit FP, which the SHARC also seems to do, might be more suitable.
SHARCs, particularly the new, dual-core devices, are massively powerful things. Really. Since it's all (or largely) single-cycle instructions, good design practice will get you up to 800 million 32-bit operations per second - equivalent to 4166 operations per sample at 192kHz (the highest samplerate anyone cares about). Also, some operations happen in parallel, such as shifting and address-register-modulo calculations, so they come for free. That's an ambitious figure, sure - but just the ballpark. To put this in a meaningful way, the long FIR filters you'd use for room correction are out, but as DSP_Geek said earlier it's often better and easier to correct room responses with IIR filters anyway (that's certainly the way I'd do it), and you can run somewhere around 140 biquad filters in total (when allowing 30 instructions per biquad to get you TPDF dither, double-precision feedback and the like). That's far more than you need if you're just doing room correction - even at the 7.1 level.
FIR filters are, just IMO, more useful in mid/top crossovers in individual loudspeakers than in room correction - however, here they do their job well with only around 600 taps or so at 192kHz. So if this box were considered for crossover duty then FIRs could be factored in, since a 600-tap FIR filter is only equivalent to 20 of the aforementioned biquads. Doing all the DSP for all that for a 7.1 system at 192kHz on a single SHARC is going to get tricky, though!
Adjustable per-channel delay comes in almost free in terms of calculation time, and per-channel gain much the same, so this could be used to make a precision preamp as well as just a DRC box.
Someone earlier pointed out that Analog Devices dev tools are much more expensive than the Xilinx ones - which they are. It's worth bearing in mind that there may well be ways of acquiring the tools, though, which would put them back on equal footing. And I doubt the corporate world cares much about the dabblings of the DIY world (although, insert disclaimer here!).
Very, very cheap FPGA dec boards can be found at http://www.digilentinc.com
Fantastic value for money, frankly, and they might lend themselves to a project like this. I have no connection to the company, btw - and I haven't yet bought one of their boards. It seems likely that I will. FPGAs as a paradigm seem quite ideally suited to what it is that we want to do here, both in terms of flexibility and in terms of what they offer in hardware, such as their programmable clock managers. There are free blocks such as AES/EBU or S/PDIF transmitters/receivers that can be simply duplicated in the FPGA to give you as many inputs and outputs as you want for your application - all you'd need to provide would be the physical layer stuff like isolation transformers.
One point I came up against when thinking about the Xilinx Spartan3 chips is they only have 18-bit multipliers in the hardware. Which is annoying. This would either limit us to 18-bit audio input or require us to gang up multiple multipliers and go double-precision - giving 36x36->72-bit multiplies, which is clearly quite a waste of silicon. Depending on the device, clock rates and the overall design, it might be workable. It just feels a bit inefficient is all.
One point that springs to mind: the Blackfin processor has been mentioned several times. The salient point about the Blackfin is that it's a 16/32-bit processor, with a 16-bit MAC and 40-bit accumulators. It's really designed for doing 16/32-bit calculations, which isn't enough for high-quality audio coming in at 24-bit. The SHARC, on the other hand, has a 32-bit MAC and 80-bit accumulators, which is nigh-on perfect. You could misuse it and do double-precision operations but that's really slow and it's better just to use better hardware. The SHARC does do floating-point, although I wouldn't use 32-bit floating-point for audio (see my other threads for the reasons why). 40-bit FP, which the SHARC also seems to do, might be more suitable.
SHARCs, particularly the new, dual-core devices, are massively powerful things. Really. Since it's all (or largely) single-cycle instructions, good design practice will get you up to 800 million 32-bit operations per second - equivalent to 4166 operations per sample at 192kHz (the highest samplerate anyone cares about). Also, some operations happen in parallel, such as shifting and address-register-modulo calculations, so they come for free. That's an ambitious figure, sure - but just the ballpark. To put this in a meaningful way, the long FIR filters you'd use for room correction are out, but as DSP_Geek said earlier it's often better and easier to correct room responses with IIR filters anyway (that's certainly the way I'd do it), and you can run somewhere around 140 biquad filters in total (when allowing 30 instructions per biquad to get you TPDF dither, double-precision feedback and the like). That's far more than you need if you're just doing room correction - even at the 7.1 level.
FIR filters are, just IMO, more useful in mid/top crossovers in individual loudspeakers than in room correction - however, here they do their job well with only around 600 taps or so at 192kHz. So if this box were considered for crossover duty then FIRs could be factored in, since a 600-tap FIR filter is only equivalent to 20 of the aforementioned biquads. Doing all the DSP for all that for a 7.1 system at 192kHz on a single SHARC is going to get tricky, though!
Adjustable per-channel delay comes in almost free in terms of calculation time, and per-channel gain much the same, so this could be used to make a precision preamp as well as just a DRC box.
Someone earlier pointed out that Analog Devices dev tools are much more expensive than the Xilinx ones - which they are. It's worth bearing in mind that there may well be ways of acquiring the tools, though, which would put them back on equal footing. And I doubt the corporate world cares much about the dabblings of the DIY world (although, insert disclaimer here!).
Very, very cheap FPGA dec boards can be found at http://www.digilentinc.com
Fantastic value for money, frankly, and they might lend themselves to a project like this. I have no connection to the company, btw - and I haven't yet bought one of their boards. It seems likely that I will. FPGAs as a paradigm seem quite ideally suited to what it is that we want to do here, both in terms of flexibility and in terms of what they offer in hardware, such as their programmable clock managers. There are free blocks such as AES/EBU or S/PDIF transmitters/receivers that can be simply duplicated in the FPGA to give you as many inputs and outputs as you want for your application - all you'd need to provide would be the physical layer stuff like isolation transformers.
One point I came up against when thinking about the Xilinx Spartan3 chips is they only have 18-bit multipliers in the hardware. Which is annoying. This would either limit us to 18-bit audio input or require us to gang up multiple multipliers and go double-precision - giving 36x36->72-bit multiplies, which is clearly quite a waste of silicon. Depending on the device, clock rates and the overall design, it might be workable. It just feels a bit inefficient is all.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.