Topping DX7 uses ES9038PRO ASRC. IMO either ASRC or FIFO is needed to have ultra low jitter from SPDIF. But how low jitter needs to be is another thing altogether. There are highly regarded dacs that use cs8412/4.
I get what you are saying in principle. Its that I can't recall a modern USB board marketed for diy use that is constrained in the way you are describing. Is there one? If there is, why use it?
The whole external DAC thingie seems to be a profitable market. Market will probably be best served commercially leaving out DAC sections in audio players completely so companies can always sell 2 devices. The "flat TV-soundbar" construction.
Less = more.
Bohrok, I know of YM3623B and CS4312 receiver based DACs that are jittery as hell and lowering the jitter makes the owners displeased. Tube guys so no discussion possible and almost never normal standardization in many aspects so honest comparison with modern DACs is near impossible.
Less = more.
Bohrok, I know of YM3623B and CS4312 receiver based DACs that are jittery as hell and lowering the jitter makes the owners displeased. Tube guys so no discussion possible and almost never normal standardization in many aspects so honest comparison with modern DACs is near impossible.
Last edited:
OP is planning to use Teensy 4.1 or MCU that is similar. You are the one pushing commercial USB boards.
Jitter can sometimes add some edge to the sound that helps cut through other muddy-sound problems, and or it can make instruments like violins (with their particular harmonic structure) sound more real on a mediocre/poor system. Of course other instruments end up sounding less real. Seems to depend a lot on the system and the particular jitter's frequency/phase variation over time (e.g. if it is more or less deterministic jitter).
Last edited:
Maybe this would be a good time to recap the state of some of the discussion involved with DAC/DSP/Class-D implementation and or integration. Cost, complexity, performance goals, etc.
Cheap and simple seems like it goes with Teensy and something like ES9023P. In that case cost and simplicity would seem to be the main goals.
Maybe that would be good something like car audio. A higher level use-case might be, say, computer gaming with surround sound and one or more subwoofers. Something like that. Consumer living room hi-fi and or home theater might be up one more level, where cost, complexity, and performance are all more elevated. At one extreme there is high end audio reproduction in a dedicated room with large panel electrostatic speakers, maybe optical phono, and or other fancy stuff. Certainly there are some existing home theater and or hi-fi systems that cost a few $100k to implement. Most of those are not optimal in the sense that not all the money was well spent, but the intent of trying to make everything the best it can be was still the primary goal. Cost was secondary for some of those installations.
Anyway, no matter what the end goals, there is always a risk when integrating subsystems that there may unexpected performance issues that require troubleshooting. With that concern in mind, especially for a new designer of audio systems, it seemed like an incremental approach to build and test of one subsystem at a time might be wise. Say, once baseline performance of a dac can be determined, then other subsystems can be added and checked to see if they degrade established baseline performance. At least that ways its probably easier to troubleshoot, identify, and correct whatever might be causing a problem. For incremental testing of a dac, using a proven quality USB board that can send clean, low-jitter I2S signals to the dac should be able to give some confidence the I2S source is probably not to blame if dac performance does not meet expectations. However, there is a cost to being able to do such a test. A decent USB board is needed, and probably a good soundcard too (for FFT analysis 🙂 ). Notch filter and makeup gain nice to have as well. In fact doesn't @IVX make a notch/gain box for that which can make any old sound card (like in a PC) work pretty well for basic measurements?
Don't want to get ahead of myself though. Before a build and test plan can be formulated, its helpful to understand some of the design tradeoffs that will likely affect cost, complexity, and performance for the project. Seems like recently we have been getting into what might be involved with some of those tradeoffs. Don't think we have exhausted it all yet, but hopefully options/tradeoffs are starting to become more clear. For me at least, SQ is most valued, so I want to continue to learn how to optimize that. For the OP, hard to say if the end goals are becoming more clear or maybe if its getting closer to the time to work on narrowing them down some? Is this going to be easy and low cost above all? Is there a cost ceiling? Is test equipment included in the project budget or can test equipment be amortized over a longer time period?
Cheap and simple seems like it goes with Teensy and something like ES9023P. In that case cost and simplicity would seem to be the main goals.
Maybe that would be good something like car audio. A higher level use-case might be, say, computer gaming with surround sound and one or more subwoofers. Something like that. Consumer living room hi-fi and or home theater might be up one more level, where cost, complexity, and performance are all more elevated. At one extreme there is high end audio reproduction in a dedicated room with large panel electrostatic speakers, maybe optical phono, and or other fancy stuff. Certainly there are some existing home theater and or hi-fi systems that cost a few $100k to implement. Most of those are not optimal in the sense that not all the money was well spent, but the intent of trying to make everything the best it can be was still the primary goal. Cost was secondary for some of those installations.
Anyway, no matter what the end goals, there is always a risk when integrating subsystems that there may unexpected performance issues that require troubleshooting. With that concern in mind, especially for a new designer of audio systems, it seemed like an incremental approach to build and test of one subsystem at a time might be wise. Say, once baseline performance of a dac can be determined, then other subsystems can be added and checked to see if they degrade established baseline performance. At least that ways its probably easier to troubleshoot, identify, and correct whatever might be causing a problem. For incremental testing of a dac, using a proven quality USB board that can send clean, low-jitter I2S signals to the dac should be able to give some confidence the I2S source is probably not to blame if dac performance does not meet expectations. However, there is a cost to being able to do such a test. A decent USB board is needed, and probably a good soundcard too (for FFT analysis 🙂 ). Notch filter and makeup gain nice to have as well. In fact doesn't @IVX make a notch/gain box for that which can make any old sound card (like in a PC) work pretty well for basic measurements?
Don't want to get ahead of myself though. Before a build and test plan can be formulated, its helpful to understand some of the design tradeoffs that will likely affect cost, complexity, and performance for the project. Seems like recently we have been getting into what might be involved with some of those tradeoffs. Don't think we have exhausted it all yet, but hopefully options/tradeoffs are starting to become more clear. For me at least, SQ is most valued, so I want to continue to learn how to optimize that. For the OP, hard to say if the end goals are becoming more clear or maybe if its getting closer to the time to work on narrowing them down some? Is this going to be easy and low cost above all? Is there a cost ceiling? Is test equipment included in the project budget or can test equipment be amortized over a longer time period?
Last edited:
IIUC OP plans to use Teensy as a development board for the MCU. DAC will be ES9033 which should be quite suitable even for hifi. So this is not about cost and simplicity.
Other than that I agree that incremental or modular approach would be best. IMO stuffing everything on the same board has many risks compared to having e.g. the DAC on a separate board. Added complexity increases the possibility of layout errors. If DAC needs to be upgraded only the DAC board needs modification. Once every module is ok and satisfactory it is fairly easy to put them in one board if that is the ultimate goal.
Other than that I agree that incremental or modular approach would be best. IMO stuffing everything on the same board has many risks compared to having e.g. the DAC on a separate board. Added complexity increases the possibility of layout errors. If DAC needs to be upgraded only the DAC board needs modification. Once every module is ok and satisfactory it is fairly easy to put them in one board if that is the ultimate goal.
Built-in audio inputs would have very different distortion levels. Some of them -80db, others -100db. -100db-30db=-130db of Cosmos APU is kind of Ok resolution for entry DIY level but -80db-30db=-110db is 100% sucks. However, you still have a chance to readjust 1kHz notch(2 trimpots) for -40db ratio to get -120db of the notch resolution. For the 10kHz is probably no way without replacing parts.
I 100% agree with #266 and #267!
I already had the idea in mind to make the MCU + USB a daughter board that either can be attached via headers or later on, soldered directly to the main board via castellated holes. One reason is that I just don't know if I'm able to solder BGA. I have a reflow oven but it's just a cheap one and getting the profile right isn't that easy.
As @Markw4 mentioned having a USB board that I can rely on is a good idea, the teensy is fine for simple functional tests, having a better board, later on, will surely help.
The price/performance discussion will be interesting too, right now I do not try to build a Hifi board, but it should perform reasonably well, aiming for <100 € BOM + PCB cost. But that's not the real constraint for now.
Right now I try to lower complexity while keeping some flexibility, the "Eierlegendewollmilchsau" does not exist and decisions have to be made.
Test equipment... well, I'm a tool junky and the next thing I will build is an ARTA box, apparently, it's pretty useful for measuring speakers. getting a PC audio interface analyzer would be interesting too. A topic for another day.
So the plan for now:
I already had the idea in mind to make the MCU + USB a daughter board that either can be attached via headers or later on, soldered directly to the main board via castellated holes. One reason is that I just don't know if I'm able to solder BGA. I have a reflow oven but it's just a cheap one and getting the profile right isn't that easy.
As @Markw4 mentioned having a USB board that I can rely on is a good idea, the teensy is fine for simple functional tests, having a better board, later on, will surely help.
The price/performance discussion will be interesting too, right now I do not try to build a Hifi board, but it should perform reasonably well, aiming for <100 € BOM + PCB cost. But that's not the real constraint for now.
Right now I try to lower complexity while keeping some flexibility, the "Eierlegendewollmilchsau" does not exist and decisions have to be made.
Test equipment... well, I'm a tool junky and the next thing I will build is an ARTA box, apparently, it's pretty useful for measuring speakers. getting a PC audio interface analyzer would be interesting too. A topic for another day.
So the plan for now:
- Finish the DAC + related components, including LDO and Clock
- testing testing testing
- have a mental breakdown because it's not working at all.
- return to step 1
For soldering BGA you would most likely need a stencil. The problem is that stencils are expensive and for every new layout you may need a new stencil. So for development phase it would be good to have a package that is more diy-friendly.
Yea I know, but I think BGA comes with balls already attached, hence the name (hopefully). That's one reason I opted for making a separate board prototype board for the DAC, maybe it's useful enough to keep it that way, who knows?
I will focus on implementing a clock for the DAC, now. As you said, having a USB with an external clock might lead to problems, but for now, it's a good idea to have a dedicated clock for the DAC.
Small update on the PCB for the DAC IC.
I think I have layout and routing done now, the one thing I`m still struggling with is the clock. I use a fairly simple 4Pin tri-state ECS-2520 clock, due to availability, I will change it when moving to a more refined design, but the lack of options hinders prototyping.
What I don't understand is if I have to include caps for the load capacity near the crystal, I have seen oscillator networks using 2 caps according to the load-capacitance of the crystal on the in- and output. Is this needed in my case too where I only have a clock input and if so, how do I calculate it?
Should I include a series resistor at the clock-in?
Should I rout MCLK to a pin or is this a bad idea? I left the header pin unconnected for now.
More filtering at Vin before the LDO could be implemented too, should I do so?
I was able to rout all signals on the top layer of the board, therefore the stackup is now S - GND - GND - PWR, with the Bottom layer as a solid fill
All of the IOs are on headers
Have a nice weekend,
Best
Fabian
I think I have layout and routing done now, the one thing I`m still struggling with is the clock. I use a fairly simple 4Pin tri-state ECS-2520 clock, due to availability, I will change it when moving to a more refined design, but the lack of options hinders prototyping.
What I don't understand is if I have to include caps for the load capacity near the crystal, I have seen oscillator networks using 2 caps according to the load-capacitance of the crystal on the in- and output. Is this needed in my case too where I only have a clock input and if so, how do I calculate it?
Should I include a series resistor at the clock-in?
Should I rout MCLK to a pin or is this a bad idea? I left the header pin unconnected for now.
More filtering at Vin before the LDO could be implemented too, should I do so?
I was able to rout all signals on the top layer of the board, therefore the stackup is now S - GND - GND - PWR, with the Bottom layer as a solid fill
All of the IOs are on headers
Have a nice weekend,
Best
Fabian
I would add a local decoupling cap (100nF) close to clock. Also a series termination resistor on output. The value of this can be tuned when testing. I would also route MCK to clock output and add a jumper for clock enable so that it can be disabled if external MCK is used.
10uF X7R should be sufficient.
If you are going to export your MCLK to a DSP board or somewhere you might want to add a clock buffer such as NB3L553-D, or at least use a single-logic inverter as a buffer.
Also, every I2S and MCLK signal connector should have one dedicated ground pin for each signal pin (since this is RF we are dealing with). Most commonly there are two rows of pins with one row being all grounds.
I2C also requires a ground pin. Same for analog outputs.
Mounting holes are most commonly not grounded.
Using 1uf caps for dac chip bypass is not usually a good idea. Bypass caps are usually in the range of .1uf to .01uf (since they need to have low impedance at RF).
Last thing, using LT3042 for what you have there is overkill. If you are going to use it, better study the advice in the datasheet very carefully or it will not come close to working the way its supposed to. IME it will probably be less noisy if you use a linear cap for Cset. In that case 47uf is too big. A linear 4.7uf or maybe 10uf cap would probably be what I would use. SMD film caps are available in those values.
Also, every I2S and MCLK signal connector should have one dedicated ground pin for each signal pin (since this is RF we are dealing with). Most commonly there are two rows of pins with one row being all grounds.
I2C also requires a ground pin. Same for analog outputs.
Mounting holes are most commonly not grounded.
Using 1uf caps for dac chip bypass is not usually a good idea. Bypass caps are usually in the range of .1uf to .01uf (since they need to have low impedance at RF).
Last thing, using LT3042 for what you have there is overkill. If you are going to use it, better study the advice in the datasheet very carefully or it will not come close to working the way its supposed to. IME it will probably be less noisy if you use a linear cap for Cset. In that case 47uf is too big. A linear 4.7uf or maybe 10uf cap would probably be what I would use. SMD film caps are available in those values.
Last edited:
Hey,
hopefully, it will work as intended.
Thank you all, you will hear from me when I have done my homework.
best
I thought about that and will implement it. TY
It was probably a typo, changed the value to 4u7
I implemented the LT3042 as close as possible to the datasheet and ref design as I could, including the odd pad spitting of Cout
hopefully, it will work as intended.
Good Idea!
Thank you all, you will hear from me when I have done my homework.
best
Instead of using that LT3042 as you are, you could save some money and likely get better SQ by using a cheap 3-terminal SMD regulator for each load. The LT3042 could still be used in a helpful way if you want to drop the incoming voltage down to 5v. The 3-terminal regulators could drop that 5v down to 3.3v for each load. Its simple, cheap, and it would work better.
https://www.mouser.com/c/semiconduc...Package / Case|~PSRR / Ripple Rejection - Typ
https://www.mouser.com/c/semiconduc...Package / Case|~PSRR / Ripple Rejection - Typ
Well, he seems stuck on the idea of using an LT3042 for some reason. Didn't you advise using separate regulators for each load?
Your LT3042 implementation seems to be ok. I use tantalums as Cset. Higher Cset brings lower lf noise but no need to go higher than 22uF. No need for film caps.
Instead of single LT3042 you could use multiple e.g. NCP163 or LP5907 as Markw4 suggested but as pre-regulator no need to use anything better than LM317 or 7805. If you already have LT3042s I see no reason to change your latest design for first iteration.
Each load will create noise that interacts with the other loads. The noise will also propagate back towards the LT3042. Some of the noise transients will be attenuated by the LT3042 output cap. IIRC from the datasheet using a larger output cap can improve transient response, but at the expense of lowering LT3042 regulation bandwidth. For noise that is not attenuated by the output cap, LT3042 error amplifier will attempt to cause LT3042 output transistor to turn either more on, or else more off. When it turns on harder it can raise the output voltage by drawing current from the input cap. The first thing that will happen in that case is that the output cap will start to charge back up. If needed, to lower the output voltage LT3042 will just have to wait for the loads to absorb the voltage since LT3042 is a single quadrant regulator. It has no direct way of turning down the output voltage. As result of all the above, you will probably be better off with separate regulators for each load. If you want to keep the LT3042 for some reason you could still do that too, even if some people might laugh. They might laugh at what you are doing already for that matter.