[Fpga-synth] New project - ARM & FPGA Audio board

[Magnus Danielson]

Eric Brombaugh skrev:
> Magnus Danielson wrote:
>> Eric Brombaugh skrev:
>>> Let me know what you think!
>>
>> I had one comments from a friend of mine which is deep into precission 
>> and he made the note that the S/N ration of the A/D and D/A could be a 
>> few dB better... it was not up to state of the art. I'll try to get 
>> detailed feedback (will most probably be in the form of the schematic).
> 
> No doubt the CS4270 codec I'm using is not the pinnacle of audio 
> performance. I haven't gone out of my way to optimize the layout for 
> best analog/digital isolation either. It will be interesting to see how 
> well it works.

Indeed.

>> I think it really depends on what you expect it to be I guess.
> 
> Managing expectations is critical, and my goal here is to have something 
> that sounds decent but not necessarily excellent to perfect.

I agree. Good enought to be able to toy around, but not intended to be 
the audio reference in the lab.

> Someone I 
> know has an Audio Precision analyzer - hopefully he'll let me hook this 
> up when I build it to see what the SNR actually is. If it's not great 
> then I'll see what can be done for Rev 2.

I have a AP SYS-2722 at work. We have never used the A/D and D/A tests 
in it, but this seems like a good time to do it. :)

>> I commented that you can always hook a better CODEC on the outside 
>> anyway, when you need it. Could be good to recall.
> 
> Yes - use AES/EBU or SP/DIF to drive high-end audiophile and/or 
> studio-quality equipment.

You can also use the auxilary pins to hook up a board with more direct 
interface of your choice.

>> He also asked if it could pull of real-time (back-to-back) 1 Msamples 
>> 64 bit FFT for a 200 kS/s rate. By a quick exambination it looks not 
>> all that impossible really. The multiplier blocks needs to be combined 
>> to create sufficient bit-resolution. I think it is mostly an issue 
>> about coding abilities than anything else.
> 
> Real-time FFTs would be pretty nifty. I'm not sure if there are 
> sufficient resources for super-high resolution transforms in the FPGA 
> I've specified, but the footprint is compatible with the next size up so 
> you could grow to 500kgates if necessary for only a few more $$.

I think memory is the real limitation. 64 Mbit is needed for an in-place 
algorithm. Yeah, that is what makes it break.

> BTW - an off-list discussion with someone has revealed a simple way to 
> double the external SRAM. I've made some minor updates to the schematic 
> & layout to reflect this and have updated the website.

Great! More RAM to the people!

Cheers,
Magnus