Open Source DAC R&D Project

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Theory vs practice

Never said anything different. But it has a limited number of samples to work with and as the usual chips are designed for varispeed etc. they will not use a vary large number of samples.

No digital source that I'm aware of has so far produced an infinite number of samples. So yeah, there are indeed only a limited number of samples to work with in the universe that I'm aware of. But you were saying that it only worked with the samples it held in its buffer (how you arrived at your 441Hz corner figure estimate), which is simply false. How about coming clean about that?;)

Now, under what conditions is the "slow mode" engaged? When you have tons of input jitter? Or if the input jitter is minimised?

Dunno, I only studied the datasheet to examine if your original assertions were true or not. If you would like to know, the datasheet is available at AD's site.

It is amusing to send a large amount of jitter into an ASRC and then see what it does, in a close in FFT. It is even more instructive to do the same thing afterwards with a well designed secondary PLL reclocker.

Each to their own. Were you being paid to do this or just did it on a whim? I don't doubt that the results will be in accord with the theory of ASRCs, so myself I'd take that route...

Actually, I looked to fair degree "under the hood" and I find observed performance to varying degrees inconsistent with the supposed and/or assumed theory of operation to question if "under the hood" things really work like they should.

Well if the subject is implementation rather than theory, I bow to your more extensive experience.:cool: I don't happen to think that individual SRC implementations are perfect embodiments of the theory.
 
The result in mathematical terms for a multi-stage filter should the same as for a single pass. As said, I still remember essentially identically working filters in analog hardware.

Never said anything different ;) But implementations are done by people making trade-offs, and usually those people aren't the psychoacousticians. They often turn out to be strongly influenced by accountants. My memory of colour TV sets only extends as far as luma delay lines, not SAW filters. Perhaps a SAW filter is what's inside the delay line, but as far as I was aware, it was just a delay, not a filter. I don't dispute that analogue FIR filters can be built - Hawksford I think introduced me to them.

So, why do my measurements of sending an impulse to a DAC first without digital filtering and then with show different peak amplitudes? If the ooriginal sample is preserved, should I not get the same peak amplitude?

How did the impulse get into the DAC? By legitimate means through an A/D converter from the real world, or by some back-door method? (A serious question even though I phrase it rather colloquially).
 
AX tech editor
Joined 2002
Paid Member
Hi,



Not quite. First, the rate estimator cannot really be "off". It will have to follow the source sample rate or risk running out of samples (if that sounds like a PLL, that is correct, it is basically a digital PLL).

If it does have to track the source, it will dynamically switch between different digital filters. So the input jitter is converted into different digital filter responses, which means phase (and frequency) response modulation, on top of some amplitude modulation.

If the result is more or less audible than the original jitter and/or more annoying is another story and in general seems a quite complex issue.

Ciao T

So the Rate Estimator cannot be off in a long term sense, but it can certainly waffle about. And the way I visualize it (which admittedly may be a primitive way) is that the additional samples are generated (and the original sample is 'sampled' towards to output) at a slightly wrong moment meaning they get the wrong value. Then, the final (assumed jitter-free clock) outputs those samples perfectly timed, but with the wrong value. Makes sense?

jd
 
Hi,

So the Rate Estimator cannot be off in a long term sense, but it can certainly waffle about.

Much depends on implementation. Clearly it must switch between different filters to ensure it never under/overruns its internal buffer. In that way it is basically the same as a secondary oscillator plus FiFo Buffer with suitable management to ensure the FiFo is maintained at around halve full.

Except it is a bit more complex because it must workout which filter coefficients to select. Having worked on something like that recently (largely due to the various failures of ASRC Chips to deliver what they promise) I can say that it takes a very long time domain view before you can match rates very closely.

The issue is that you have a limited precision to your counter for comparison between reference frequency and actual incoming frequency. So to work out exactly what the frequency is you must use a large number of samples to count, to improve time resolution.

So, to get a really good average that allows you to lock the system to one particular filter, you need a peak-peak jitter that is small enough to not cause issues and enough samples to get a rather precise average.

Anyway, the problem is the same as always and the solutions based on measurements and listening are not good enough and the digital filters inside ASRC's... Brrrr....

Ciao T
 
Some design questions

I dug into the design a bit and a few more questions.

The WM8805 S/PDIF transceiver needs a few bytes to configure it, I am set up for the AVR line of microcontrollers and can write some code for that (which should be reviewed by others for correctness). Hurtig was willing too?
Is their a user-interface for this beast? A switch/leds or an alpha-lcd? Not sure what you had in mind.

About the DAC schematic Rev 0.1(2) :
CS4398 in hardware mode: left-justified, up to 24 bit data, double speed 50kHz to 100kHz sample rate. I think that's 96kHz with 24.576MHz clock.
M2, M3 need to be high for quad speed 100-200 kHz sample rate, We're not going to 192kHz?
SRC4192 in hardware mode, left-justified, 24 bit data, output port master mode RCLK with 256*fs = 96kHz.

The analog Vreg's are +5 and -2.5V? Can you check R510, R511. TR502 is for +/12V Vregs, I estimate. CS4398 full scale differential output voltage 136% x VA = 6.8Vpp and your O/P stage gain is 1.

If we're not using the PLL in the CS8416, then VA/VD1 can be tied to VD2, to save some parts and vreg.
 
Hi,

The WM8805 S/PDIF transceiver needs a few bytes to configure it, I am set up for the AVR line of microcontrollers and can write some code for that (which should be reviewed by others for correctness).

Some thoughts. The 8805 has problems distinguishing between 176.4KHz and 192KHz sample rate. This can be quite easily rectified using a MCU and a little code.

Another nice thing would be to set the 8805 so it can use the same clock as the ASRC's masterclock, in software mode this is possible.

Finally, some control over the input selection needs either "up/down" buttons and up to 8 LED's or direct buttons and Leds. Maybe throw in another LED for "lock" and a few more to indicate received sample rates.

In addition, if we do not have provision options for plug-in DAC's, how about at least pin-headers at the I2S signals before and after the ASRC?

Ciao T
 
Hi,

Why bother ? It all comes out the same after the ASRC, irrespective of the incoming rate.

It does. So the output from the ASRC when fed with a 16Bit/44.1KHz signal and when fed a 24Bit/192KHz signal is identical? I think not.

So it may be of interest to know what comes in. Especially if like me you play evrything from a PC with transparent handling of sample rates... Just academic in most sense, I know.

Ciao T

Now Playing: Bap - Verdamp Lang Her
 
An indication of input sample rate is not on top of our ToDo list. If you are using your pc to feed the digital signal into the DAC, I guess you can read the sample rate on the pc (Which will be the most natural user interface). Why would you go to the DAC, to see what you are playing on the PC?? :rolleyes:
 
There has been much talk about our choice of DAC chip. The CS4398 from Crystal Semiconductors/Cirrus Logic. The choice is made purely by listening tests, which may not be the case for all those talking bad about CS4398. I feel that the anger against CS4398, is mostly related to the fact, that some people have decided not to like anything starting with "CS".
We really do not agree!

However, we have given the DAC choice some extra attention. Based on the sonic-test made during our last DAC project, we still believe that CS4398 is the best sonic performer on the market, even though the difference between flagship DAC's aren't that great.
But since some people seem to be more into a chip not starting with "CS", we may pick up something else.
I do not believe that we will end up with a Wolfson, since we consider them to be to low end. Guess that's the reason they are selling them so cheap :D
We have heard from a few users, that the CS4398 is limited in performance, due to the use of bad technology. I wonder why they managed to squeeze a THD of -107dB out of it in 2003, and why Wolfson using a stated better technology, still struggle to achieve -104dB in 2009 :D

But we will give them a try!

Also we will try PCM1794A (again), using passiv I/V converting and naturally a fully discrete No NFB analog stage. PCM1794A spec says THD = -108dB which is 1dB better than CS4398 and 4dB better than the best Wolfson DAC.
 
Hi,

If you trust your own ears and design decisions, then simply ignore all these people who second guess your choices. Let them build their own DACs. This is DIY, not DWID (do what I do).

In pirnciple, for DIY, strictly, you are absolutely right. In fact,when people told me that non-oversampling could "not work", that the TDA1541A was ancient and no good and so on, I always took the high road of ignoring such comments.

The issue here is that K + H have already made their own peersonal "DIY" Dac, one they feel (possibly quite rightly) most average DIY'ers cannot sucessfully build, but which they themselves (if not neccesarrily their interlocutors) enjoy immensely.

Now in this particular project they do not want to make a DAC for themselves, but they want to give the community a "Open Sauce" design, with PCB's likely being able to be ordered from any PCB makers and parts to be purchased from Digikey, Mouser, Farnell or RS-Components.

And by the looks no "compulsory" group buys involved either, no commercial interrests etc. (I have studiously avoided making much reference to what I do commercially - too many already use this supposed Idea exchange as a source of income - both by dredging it for designs to commercialise and by then attempting to sell the results back to the community).

So on principle I much applaud K + H in their endeavour.

And the only thing in it for K + H is the glory of seeing a lot people build their DAC and send them thank you notes.

And this is the reason several of the old hands here on the board (I used to post under a different ID for most of the "10 Year burn in") have been chiming in. That and because K + H actually asked for input.

Because with the original proposal (CS4398 DAC with CS8416 and Op-Amp's to be able to be build in DIY for around 200 USD without casework), I at least felt that it would have been wasted effort, as the same can be bought fully assembled and working, with casework for less than the cost for PCB and Parts for this project.

So, my recommendation to K + H remains, if they want to give their public project they may wish to consider finding ways to significantly push it past the "same as cheap chinese junk of e-bay" style.

In the end it's up to K + H to make their choices and publish their project. And it is theirs to consider how much the current debates will help make their project as popular as (say) the Pass Zen projects and such things.

Ciao T
 
Hey you Guys.

This project is an open source project, and also an open project in regard of sugestions for the design of the circuits and choice of chips and technology.

Actually we are both thankfull for every sugestion made in this thread, because sometimes that makes one or both of us dig into matters that else not would be investigated or even tried out.
So please keep it coming boys.
Thorsten is in fact pretty close to the very essence of the procedure, we are namely not making a DAC for ourselves this time, but instead a DAC where we try to carry the technology as fas as it gets for some 200$.
In this procedure we will try not to make any unnecessary compromises, to keep costs low, just as we do not want to implement expensive technology, if it does not do any good for sound quality anyway.

Ie.
We will use one stereo DAC chip only, even if we could accomplish better DNR by using 2 or 4 pcs. This because we cannot bring this extra DNR to your ears anyway, because it is impossible to design an analog stage transparent enough to do so.
Thus we will keep focus on the most important matters, and not let us get carried away by hot news and fantasy data.
In other words, we will try to look where the problems to solve are, and not just where the light falls.
This is harder than you think, because it is easy to compare data, sample rate and bit depth, and 32 bits is more precise than 24, everyone knows that, but increasing DNR from 130 dB to 160 dB makes IMHO no sense at all.

The most conservative of us after all is Hurtig, who actually is the younger of us, and the one that initiated this project. He would like to use the CS4398 in this project also, which I would not do. He wants to do so because of the results we achieved in the earlier project with cs4398.
I do not think we will get anywhere near that in this project anyway, but IMHO this is not needed at all.
This project is to be done in the traditional way, first you open a discussion, then everybody makes their point(s), and then the most promising and reasonable solutions are chosen.
Then design, layout, test and if it works fine, then done.
This is how most electronics are designed, commercially ones might just have even more focus on costs and eyecatching technology (32 bits, 8 stereo DAC chips, 132 dB DNR, battery supplies, large capacitor banks, huge transformers and other redicularities )
 
Last edited:
Hi,
It does. So the output from the ASRC when fed with a 16Bit/44.1KHz signal and when fed a 24Bit/192KHz signal is identical? I think not.

Then perhaps a rethink is in order. Whatever goes in will come out at a fixed rate determined sample rate of the output side. Set the output to 20/96 and that is what will come out irrespective of whether the input is 16/44 or 24/192.
 
Then perhaps a rethink is in order. Whatever goes in will come out at a fixed rate determined sample rate of the output side. Set the output to 20/96 and that is what will come out irrespective of whether the input is 16/44 or 24/192.
Just right.

And I think it is time to consider, that both Analog, TI and CS have both ADC´s and DAC´s on program.
They have the possibility to compare analog signals before and after the convertion/resampling/interfacing/samplerate conversion/filtering/convertion, and IMHO, I think they have pretty good ideas of what happens when these processes goes on.
And in contrary to analog design, there is no extra cost in doing digital things the right way.
 
Last edited:
Hi,

Then perhaps a rethink is in order. Whatever goes in will come out at a fixed rate determined sample rate of the output side. Set the output to 20/96 and that is what will come out irrespective of whether the input is 16/44 or 24/192.

If so, surely the information content of the 20/96 signal output from a 16/44 source will still be only that of 16/44, just represented using larger numbers of samples and bits. Surely there is magical new information in this?

At the same time the 24/192 signal converted to 20/96 looses halve the samples and some (arguably more or less superfluous) information in terms of bits.

I think both of these cases are worth knowing.

As for the software I use on my PC, it is very much focused on the music and ease of use, it omits in the process such minutae that excite audiophiles (even though the underlaying playback engine is as audiophile as they come), so it does not tell me if a track is 16/44 or 24/176.4. I put up with that lack for all the other qualities it has.

Ciao T
 
Just right.

And I think it is time to consider, that both Analog, TI and CS have both ADC´s and DAC´s on program.
They have the possibility to compare analog signals before and after the convertion/resampling/interfacing/samplerate conversion/filtering/convertion, and IMHO, I think they have pretty good ideas of what happens when these processes goes on.
And in contrary to analog design, there is no extra cost in doing digital things the right way.

And if they didn't, I'm sure, between them, they could afford the odd Grimm/Weiss/dCS or two but I doubt they care one way or the other. That the ASRC was invented to make life easier for the broadcast industry and not as an universal audiophile cure-all is a moot point. A sale is sale.
 
Hi,



If so, surely the information content of the 20/96 signal output from a 16/44 source will still be only that of 16/44, just represented using larger numbers of samples and bits. Surely there is magical new information in this?

At the same time the 24/192 signal converted to 20/96 looses halve the samples and some (arguably more or less superfluous) information in terms of bits.

I think both of these cases are worth knowing........

Then perhaps a scrolling text display of some kind with a suitably audiophile description would be more apt. Given the proposed devices it could describe the output in degrees of blandness.
 
Hi,

Then perhaps a scrolling text display of some kind with a suitably audiophile description would be more apt. Given the proposed devices it could describe the output in degrees of blandness.

:)

I agree. Thankfully ASRC's can be bypassed easily. :p

Or completely omitted if K + H include the pinheaders I suggested. :D

Ciao T
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.