This has been my expectation (and ultimate plan) for the DAM also. At about the time Soren released the boards, I think he mentioned an eventual firmware revision that would allow just this, along with using multiple boards in a crossover. He has recently said the he's trying to get a revision out that is "final" in the sense that he doesn't want it to get too complicated (in terms of troubleshooting, etc.). I both understand this and think that, especially with the Spartan chip there, this is a shame.
Without really understanding what would be needed, I imagine that each (stereo) channel of a board would become the pos and neg legs for balanced; the firmware would parse the signal to the two separate boards; I'm not sure at all how the timing would be handled, which seems the key to making this work. Then each board's raw out would be balanced.
Last edited:
We will need one master clock working all the dam's. And probably one master FIFO sync circuit make sense also.
Maybe slave units will have clock and FIFO disabled and see I2s signals passed to them from master dam1021?
My take is that one board will be master. All the inputs and controls would be hooked up to that and clock recovery would be done on the master then distributed to the slave board(s). You'd then configure the boards to either stereo or dual mono operation. Dual mono will need to take one channel of audio and invert that for the - phase of the balanced outs, so that one ladder handles + and the other -.
There are two marked pins on the main header FPGA SLV OUT and FPGA MCLK OUT. These are likely for use in synchronising multiple boards, and with any luck will be used as FPGA SLV IN and FPGA MCLK IN on "slave" boards.
I2S is fine for sending complete audio signal between devices, but I'd guess the master will act as a "traffic cop" and distribute channels more directly to slave boards. The undocumented header J9 appears to provide a direct connection to the FPGA. My guess is that this header will be used for data communication between boards. If Søren is really nice to us it will be configured in such a way that the connector acts as a master bus, which would make it simple to stack multiple boards.
Obviously Søren has put a lot of thought into how it will work and I'm sure he has has an elegant solution to the problem of keeping all the plates spinning.
Last edited:
You’re probably have this one nailed Paul. Been wondering about J9. And you're right, Søren already had this planned long before we ever heard about these boards
As I see it there are two ways to do this.
Either feed identical data stream and synced clock to all units and let each unit make audio out of it according to local firmware and filters (inkl final and prefase)
Or create one master and dumb down the slaves.
First one might open up for new ideas later on not yet thought of for the dam1021. For instance if someone would want to make a 3 way with 4x boards where mid channels are balanced using 2x boards, bath super-tweeter get 1x board and bass get 1x board. This will probably start to get very fiddly if the slaves are dumbed down with all logic given to the master.
edit: But single master do have one thing going for it. Easy crossover filter loading.
As I see it there are two ways to do this.
Either feed identical data stream and synced clock to all units and let each unit make audio out of it according to local firmware and filters (inkl final and prefase)
Or create one master and dumb down the slaves.
First one might open up for new ideas later on not yet thought of for the dam1021. For instance if someone would want to make a 3 way with 4x boards where mid channels are balanced using 2x boards, bath super-tweeter get 1x board and bass get 1x board. This will probably start to get very fiddly if the slaves are dumbed down with all logic given to the master.
edit: But single master do have one thing going for it. Easy crossover filter loading.
Last edited:
The problem is more that creating an "interim feature bump" release will require time to back-port selected features from the main development code. Søren would have to create a new branch of his code base from the current release firmware to do this. Effectively he would need to be simultaneously working on two separate code bases, applying selected changes to both, and major changes only to the development branch.
Given that the x-over // dual mono features will require a substantial amount of code and are likely to require changes to the existing firmware, it would not be a straight forward task to maintain the two separate development code bases.
Anyway my take is it's far better for Søren to direct his time and efforts to working on a single, major update, and documenting that once it's done, rather splintering the code and doubling his work load for no long term benefit.
I completely agree with this. My concern was mainly one of how large the task is, but you are correct; if the firmware is not linear, then needing to rewrite parts of it for more than one branch would add that much more work.
@Soren, for the next Firmware:
Would it be a lot of work to let the DAM use the msb 28bits of 32bit input?
@Soren
The inaccuracy of the ladder resistors is a systematical error, i.e. it is not random (apart from the thermal part). Thus in principle it should be possible to correct it by using something like the gamma-curve of our computer monitors as last step before sending the data to the DAC ladder (i.e. switch the bits that actually produce the desired voltage, not the one that should produce it).
This way at least the resistors in the MSB region could be corrected
... these are the ones which use the expensive high precision versions, good ...
So some code could replace expensive resistors or increase the precession beyond what you can get as (affordable) resistor tolerances.
Of cause each DAM would need to be measured individually and would have an individual gamma curve .... but if that is automated @Sokris-industidries
that should be doable.
The inaccuracy of the ladder resistors is a systematical error, i.e. it is not random (apart from the thermal part). Thus in principle it should be possible to correct it by using something like the gamma-curve of our computer monitors as last step before sending the data to the DAC ladder (i.e. switch the bits that actually produce the desired voltage, not the one that should produce it).
This way at least the resistors in the MSB region could be corrected
... these are the ones which use the expensive high precision versions, good ...
So some code could replace expensive resistors or increase the precession beyond what you can get as (affordable) resistor tolerances.
Of cause each DAM would need to be measured individually and would have an individual gamma curve .... but if that is automated @Sokris-industidries
that should be doable.@Soren
The inaccuracy of the ladder resistors is a systematical error, i.e. it is not random (apart from the thermal part). Thus in principle it should be possible to correct it by using something like the gamma-curve of our computer monitors as last step before sending the data to the DAC ladder (i.e. switch the bits that actually produce the desired voltage, not the one that should produce it).
This way at least the resistors in the MSB region could be corrected
... these are the ones which use the expensive high precision versions, good ...
So some code could replace expensive resistors or increase the precession beyond what you can get as (affordable) resistor tolerances.
Of cause each DAM would need to be measured individually and would have an individual gamma curve .... but if that is automated @Sokris-industidries
I think this is a very nice idea. I have only heard about gamma correction for monitors but not for audio
Last edited:
I like that a lot, really a lot. Thanks zfe !
When listening at 0db there's a huge amount of "fractional bits" to get the DAC perfectly linear. The only limit is when listening with volume control at low level where smallest variation is at bit level.
Calibration, or when software makes mechanics or electronics work as they should.
Would be waste of time and just add complications. No music have 28 bit content, only real use is for volume control, and my 28 bits are mostly for the bragging rights anyway....
@Soren
The inaccuracy of the ladder resistors is a systematical error, i.e. it is not random (apart from the thermal part). Thus in principle it should be possible to correct it by using something like the gamma-curve of our computer monitors as last step before sending the data to the DAC ladder (i.e. switch the bits that actually produce the desired voltage, not the one that should produce it).
This way at least the resistors in the MSB region could be corrected
... these are the ones which use the expensive high precision versions, good ...
So some code could replace expensive resistors or increase the precession beyond what you can get as (affordable) resistor tolerances.
Of cause each DAM would need to be measured individually and would have an individual gamma curve .... but if that is automated @Sokris-industidries
Actually the errors in the R-2R network is more or less random.... But I have been thinking about linearity correction, more in the line of having a slow but very precise ADC measure the DAC during manufacturing test and save a correction table in memory for xx MSB bits.
I actually have space for those parts on my test jig PCB, and it would be easy to implement in the FPGA. But on the other hand it's a question of diminishing returns, it would add significant test time, I doubt that you could hear any difference....
But when I get time I will see how good it could get, at least it might be usefull if I want to use the R-2R DAC in test equipment....
It's kinda interesting how precise and fast a monolithic SAR ADC can be, but not a monolithic non delta sigma DAC....
----
On multiple DAC's, still working on that, kinda have two options, will implement both so we can figure out what works best in the different scenarios:
Sync before reclocking FIFO, no jitter and the clock control circuit will keep them synced to around one bit rate clock pulse, which at 44.1 Ksps is .35 uS. Speed of sound is around 0.1 mm in 0.35 uS.
Sync after reclocking FIFO, a tiny bit of jitter added due to clock wiring, but synced to 0 uS. Especially if you use the first master DAC for the highest audio frequencies I doubt there would be any audible effects.
I would have liked it for experimental purposes, to ease access to the bits 25-28 with test signals when playing around and verifying strange ideas
Of cause this could be done to some extend with the volume control or by manipulating the filters, but ....Don't bother doing pre-delivery calibration.
Hi Soren,
As it's fast and easy to implement, what about leaving the DiYers the possibility to do the "perfect" calibration themselves ?
Hi Soren,
As it's fast and easy to implement, what about leaving the DiYers the possibility to do the "perfect" calibration themselves ?
Using the calibration data is easy to implement in the FPGA, basically just a couple of lookup tables, creating the calibration data is not that easy....
The straight forward approach would be very easy, you measure (DC) the voltages at the output of the DAC for one bit on all other bis off, the rest you get as superposition.
Unfortunately the voltmeters with the needed accuracy are ... uhm.... expensive.
Last edited:
I guess you have to do such measurements after you have let the dac on for a while, so that the temperature around the resistors is somehow stabilized.
P.S. I have used some kind of an old rectangular AMD Athlon aluminum cooler some millimeters above the resistors, in order to keep the temperature stable around the resistors. After a while it gets a bit hot. Although I have not measured the temperature I think it is less than 10 degrees.