ARM/DSP based open source Hi-Fi

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Thanks for the input Marce. I think you could be a great resource and not too far from me either. ;-)

I'm fairly bored right now and like to spend too much time drawing ideas with Lucid Chart. If I were to go with the ATX form factor I'm guessing we would end up with something like below and use a connector like the Samtec Searay and standardize the bus. ATX would limit the size of connector on the back plates - just big enough for mini-xlr though.

image.png
 
Last edited:
That looks nice, DDR3 ram an all, heaven.
I've spent the last 25 years designing PCB's and the enclosures to house the electronics, and still find it a fun and interesting job. in my early days I did a lot of Bus based systems based around VME and G64 (For a company called Syntel) such as this, which we did for Daresbury (Topaz later evolved into somthing bigger):
http://accelconf.web.cern.ch/accelconf/e94/PDF/EPAC1994_1551.PDF
The fun of doing something like this is you have complete freedom of size etc etc, in this case it could be made quite compact depending on the size of the daughterboards, the main processing and memory section would fit in a 100mm x 100mm area of PCB, with BGA based designs (1.0 and 0.8mm pitch) you can easily (!!) get 4000 pins in that sort of area with double sided placement.
 
Been tinkering and scheming.

1). Boot from SD as per BeagleBoard-XM
2). 1Ghz Cortex A8 and 750Mhz C674 DSP
3). HDMI 1.3a with upto 8ch PCM audio.
4). USB-OTG port
5). Gigabit LAN
6). Audiophile grade clocks for system and A/V subsystems.
7). Narrow depth ATX based form factor
8). PCIe x1
9). 6 multifunction A/V expansion bays (such as amps, crossovers, inputs, outputs).
10). 12V input - power consumption no more than 8W with no expansion cards.
11). Sametec Searay connectors for expansion boards.

Something along the lines of...

http://www.lucidchart.com/publicSegments/view/4f062690-e62c-4661-8f5d-361f0abeb665/image.png
 
Last edited:
I'd have to look at the spec, we use i2c, used it on a board 100x200, from memory this was probably over 180mm daisy chaned to 7 Codecs.
Audiophile clocks:rolleyes: wouldn't communication grade be better:D
That layout looks ok, can you create basic 2D dxf of the boards, I only have DraftSight at home (a free Dassault 2D drawing package, if you use other Dassault products such as SW).
 
Last edited:
With reference to the DM8148 DSP I have been doing some more reading regarding clock generation and management. I'm working my round the A/V subsystems to see what is the best clocking setup.

We could isolate the McASP clocks with an external oscillator directly connected to AUXOSC_X1 pad. This is a bypass of the internal DPLL LJ and can feed each McASP(n) ahclk directly. I think this would be the cleanest solution and will synchronize all McASP units to a clean reference. This same clock can also supply the i2s clock for the HDMI audio transmitter.

Quite a few registers to set...
 
I am developing an expansion board for the Mistral EVM. I was wondering if someone could look at this initial SPDIF output schematic and pcb for me and see if they can spot anything untoward.

McASP DIT mode outputs 3.3v from the DSP serial pins and I wish to output to 75ohm rca spdif. I am using a buffer to convert to SPDIF spec voltage (74LVC1G125) with a shared psu across all four drivers (LP2985).

http://www.lucidchart.com/publicSegments/view/4ef11fc8-9260-47af-8ff1-4c990a7cca9e

Let me know what you think. I've attached the pcb layout also.
 

Attachments

  • spdifoutput-v1.png
    spdifoutput-v1.png
    62.2 KB · Views: 205
Just joining in here after a quick scan of the related ARM/DSP data sheet.

It appears to me that only McASP0 and McASP1 can be clocked from an external source. McASP2, McASP3, McASP4, and McASP5 all have clock outputs only, but no external clock inputs. Granted, those four McASP units can be clocked from an internal clock that is synchronized to an external clock, but as has been mentioned earlier in this thread that would involve an additional PLL stage in between.

Thus, it appears that for critical audio, one would need to focus on McASP0 and McASP1. I note from another posting that you sacrificed some of the 10 pins on McASP1 in order to get more I/O for McASP[2-5]. I might be wrong here, but that may have been a poor tradeoff. Dropping from 5 McASP units to fewer might be a better choice if it allows more critical audio functions to be clocked from a crystal.

By the way, I have extensive experience with TMS320 development, both C language and assembly. I have not worked with this chip yet, though, and there can be vast differences in the internal peripheral capabilities from one TMS320 model to another. One of the "mistakes" that I made with a prior TMS320 (non-audio) design was to not design for more external clocking abilities. That project ended up being at the mercy of the internal signal performance, although it turned out to be fine.
 
rsaudio,

Thanks for the input. If you check page 309 of the TRM there is a diagram for the clock structure. McASP2-5 can also use an external clock sources on pads XREF_CLK0,1,2 and AUXOSC_X1 and bypassing the internal PLL.

Registers on page 513+ allow us to set the clock transmit source for each McASP2-5 tx domain.
 
Last edited:
If you check page 309 of the TRM there is a diagram for the clock structure. McASP2-5 can also use an external clock sources on pads XREF_CLK0,1,2 and AUXOSC_X1 and bypassing the internal PLL.

Registers on page 513+ allow us to set the clock transmit source for each McASP2-5 tx domain.
Thanks. I had only looked at the data sheet, SPRS647B, before you pointed out the TRM. My quick scan showed pins dedicated to McASP, so thanks for providing the schematic of how the MLB* inputs can be routed to McASP clocks.

Your project continues to look promising.
 
My only comment on the layout is leave room for stiching vias, and put one next to every component pad that goes to ground.
Also at the ends of any copper pours that run between tracks, this avoids any diopole structures being formed by the copper pours.
Some info on them:
http://ecadigitallibrary.com/pdf/57thECTC/s08p7bf.pdf
MTI TN1014 Stitch Vias

Printed Circuit Design & Fab Magazine Online

The only other thing is copper pours between the pads of small chip components (caps and res's).
I do designs both with and without copper between the pads of these small chip devices (0402...0805's), whether or not to pour between the pads depends on:
PCB bare board costs, having larger gaps and more tolerance for solder mask and copper feature to copper feature
can greatly reduce the cost of a board. Tighter boards cost more as the manufacture has to be more closely monitered.
As this board will probably have to have some impedance controll for the DDR interface, this may not be an issue.
Assembly method, if the parts are going to be hand placed, then again it is better to allow more tolerance for any miss
placing of small chip components. This is all down to the size and accuracy the solder mask is placed. With copper between pads of components
I have seen exposed copper on boards due to solder mask being increased to much and misregistration when imaged. This
has caused shorts between a pad and the ground pour, which with a decoupling capacitor is interesting.
Looking good.:D
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.