Hi,
First off all, let me just tell you that I am a total newbee in Hifi and diy hardware. So excuse my ignorance if you find me asking stupid questions. However, I have become very interested in this area the last year and I thank you for sharing all your knowledge in this forum. I have learned alot (still at theoretic level).
Let's get down to it. I am interested in building a USB DAC and couple it with a headphone amp, so that I can enjoy hi quallity music whilst working (as I am a programmer since my childhood years). At the moment I'm trying to understand how I'm supposed to build the DAC. I understand that the main problem the DAC faces is jitter in the digital stream that comes from whatever source that is connected to it.
Let's say that this source is a CD-player (not the one you find infront of a computer, but rather a real hifi CD-player). The CD-player produces a stream that is sent to the DAC. On the way to the DAC the signal collects jitter, which is a problem for the DAC-chip (say a PCM 1704, which I understand is a very good chip). The reason for this, as I understand it, is because jitter is infact problems with timing. LessLoss (www.lessloss.com) solves this problem by syncing the CD-player with the oscilator inside the DAC, and then oversamples the signal 8x (with DF 1704), thus providing a solid signal to send to the PCM 1704. All of this seem very resonable to me (as I said, I am a newbee and I don't understand all issues in this area).
Now if we get back to the USB situation. LessLoss states that the computer is a huge jitter factory and as such it cannot in any circumstances provide a jitter free signal to the DAC (even if you can do alot to lower the jitter). However, my experiences with for example a USB-memory is that I can successfully transfere a EXE-file 100 times back and forth to my computer without breaking the EXE-file. So if I had a 100% correct wave-file, I expect the behaviour to be the same.
Now you might say, yeah, but the problem occurs when streaming to the DAC. Yes I understand this. So I wonder, why can't I find any solutions where the DAC buffers the stream and then using it's own perfect oscilator, transferes a jitter free stream from the buffer (I expect that the data in the buffer should be 100% accurate at this moment) to the DAC, thus providing a 100% optimal stream for the DAC. The only answer LessLoss gives to this question is
"The quality of the oscillator is dependent on a plethora of factors, including even slightest power supply fluctuations, interference, shielding, the very schematic solution of the oscillator, ground contamination, etc."
Well, I suspect that this issue, is a problem in whatever solution one choses, even the solution is to reclock the CD-player. And I don't understand why the problem is easier to solv in a CD-player then in a small memory buffer that resides on the same board, only a short distance from the actual oscilator.
What am I missing in this scenario? Mind you that I have overlooked any problems that might occur with unstable power suply and any other design errors.
First off all, let me just tell you that I am a total newbee in Hifi and diy hardware. So excuse my ignorance if you find me asking stupid questions. However, I have become very interested in this area the last year and I thank you for sharing all your knowledge in this forum. I have learned alot (still at theoretic level).
Let's get down to it. I am interested in building a USB DAC and couple it with a headphone amp, so that I can enjoy hi quallity music whilst working (as I am a programmer since my childhood years). At the moment I'm trying to understand how I'm supposed to build the DAC. I understand that the main problem the DAC faces is jitter in the digital stream that comes from whatever source that is connected to it.
Let's say that this source is a CD-player (not the one you find infront of a computer, but rather a real hifi CD-player). The CD-player produces a stream that is sent to the DAC. On the way to the DAC the signal collects jitter, which is a problem for the DAC-chip (say a PCM 1704, which I understand is a very good chip). The reason for this, as I understand it, is because jitter is infact problems with timing. LessLoss (www.lessloss.com) solves this problem by syncing the CD-player with the oscilator inside the DAC, and then oversamples the signal 8x (with DF 1704), thus providing a solid signal to send to the PCM 1704. All of this seem very resonable to me (as I said, I am a newbee and I don't understand all issues in this area).
Now if we get back to the USB situation. LessLoss states that the computer is a huge jitter factory and as such it cannot in any circumstances provide a jitter free signal to the DAC (even if you can do alot to lower the jitter). However, my experiences with for example a USB-memory is that I can successfully transfere a EXE-file 100 times back and forth to my computer without breaking the EXE-file. So if I had a 100% correct wave-file, I expect the behaviour to be the same.
Now you might say, yeah, but the problem occurs when streaming to the DAC. Yes I understand this. So I wonder, why can't I find any solutions where the DAC buffers the stream and then using it's own perfect oscilator, transferes a jitter free stream from the buffer (I expect that the data in the buffer should be 100% accurate at this moment) to the DAC, thus providing a 100% optimal stream for the DAC. The only answer LessLoss gives to this question is
"The quality of the oscillator is dependent on a plethora of factors, including even slightest power supply fluctuations, interference, shielding, the very schematic solution of the oscillator, ground contamination, etc."
Well, I suspect that this issue, is a problem in whatever solution one choses, even the solution is to reclock the CD-player. And I don't understand why the problem is easier to solv in a CD-player then in a small memory buffer that resides on the same board, only a short distance from the actual oscilator.
What am I missing in this scenario? Mind you that I have overlooked any problems that might occur with unstable power suply and any other design errors.
Re: Re: Jitter and all that
Sorry, I didn't mean to be ignorant.
I don't belive that the signal from the buffer to the dac chip would be totaly "jitter free", I merely suggest that the stream would be totaly controled by the designer of the DAC device and as such it can be optimized.
And yes, you might be right that digital isn't perfect. However, I do beleive that the memory buffer would contain the exact bits that was transfered to it, just like the USB memory stick does.
About the latency problem. I understand that it might be a problem for a musician that plays notes on a keyboard. But for someone who listens to recorded music, I don't beleive it's such a big issue.
ezkcdude said:
Sorry, I didn't mean to be ignorant.
I don't belive that the signal from the buffer to the dac chip would be totaly "jitter free", I merely suggest that the stream would be totaly controled by the designer of the DAC device and as such it can be optimized.
And yes, you might be right that digital isn't perfect. However, I do beleive that the memory buffer would contain the exact bits that was transfered to it, just like the USB memory stick does.
About the latency problem. I understand that it might be a problem for a musician that plays notes on a keyboard. But for someone who listens to recorded music, I don't beleive it's such a big issue.
Maybe you should take a look at a DAC that's less susceptible to jitter and basically take jitter out of the equation.
Lots of non-oversampling DAC designs here that are simple to make and that will improve on most commercial DACs not costing thousands.
Some related info, though not precisely about non-oversampling.
http://www.benchmarkmedia.com/appnotes-d/jittercu.html
http://www.audiocraftersguild.com/AandE/npt.on.jitter2.htm
Lots of non-oversampling DAC designs here that are simple to make and that will improve on most commercial DACs not costing thousands.
Some related info, though not precisely about non-oversampling.
http://www.benchmarkmedia.com/appnotes-d/jittercu.html
http://www.audiocraftersguild.com/AandE/npt.on.jitter2.htm
Re: Re: Re: Jitter and all that
This is correct. There are several threads on this forum of tests comparing repeated copies of copies of music CD's bit-by-bit finding 100% accuracy. The data going to the DAC will be 100% correct. The only thing to fix is the timing. You understand the problem exactly.
Jan Didden
fixerfrasse said:
This is correct. There are several threads on this forum of tests comparing repeated copies of copies of music CD's bit-by-bit finding 100% accuracy. The data going to the DAC will be 100% correct. The only thing to fix is the timing. You understand the problem exactly.
Jan Didden
fixerfrasse said:
Pretty much. The slight downside is if the data is coming in too fast or too slow you can run out of buffer.
The best way is to fill the buffer at faster than real time speed. Reduces the latency problem and you know that you won't underrun. You can also perform re-reads of any corrupt data (if there is any at all), but for some reason reading at >1x scares the heck out of some people
I'm not worried about the filling of the buffer. What I'm worried about is that it might be hard to read the buffer without introducing jitter. I suspect a couple of factors that might be hard to cope with.
There are two actors on this buffer. One that fills it, and the other that reads it.
Will the writing actor affect the reading actor? Will this introduce jitter on the reading wire that pushes data to the DAC chip.
Can I have two separate busses that work the memory? One that write and one that reads. Maby the writing bus should be able to read aswell. Will it enhance the performance of the reading actor? Will the writing bus affect the reading bus, or can I separate them from each other so that they work totaly independent?
Is there any other issues working with memory busses that I should know of when the importance of low jitter is critical?
There are two actors on this buffer. One that fills it, and the other that reads it.
Will the writing actor affect the reading actor? Will this introduce jitter on the reading wire that pushes data to the DAC chip.
Can I have two separate busses that work the memory? One that write and one that reads. Maby the writing bus should be able to read aswell. Will it enhance the performance of the reading actor? Will the writing bus affect the reading bus, or can I separate them from each other so that they work totaly independent?
Is there any other issues working with memory busses that I should know of when the importance of low jitter is critical?
The write will only affect the read if its to the same memory location.
The actual jitter of reading the data is pretty irrelevant. Its the clock jitter at the DAC that counts. Data jitter, so long as does not violate the data inputs setup and hold timings won't have an effect, just the clock.
The clock tells the DAC when to do things, not the data.
The actual jitter of reading the data is pretty irrelevant. Its the clock jitter at the DAC that counts. Data jitter, so long as does not violate the data inputs setup and hold timings won't have an effect, just the clock.
The clock tells the DAC when to do things, not the data.
BlackCatSound said:
I don't understand what you mean with data jitter and time jitter. As far as I understand, jitter is a timer problem. Forgive my ignorance if I'm out bicycling about this.
Also I beleive that a perfectly clocked DAC chip wouldn't do a very great job if the signals transmittet to it wasn't equally good synchronised with the DAC. Therefore, the clock that runs the DAC must also run the memory bus that is suppose to hand data over to the DAC.
The problem I'm troubled about isn't really the clock. Because the clock will be wired to control both the DAC chip and the memory bus. What I want to know is if there is any unknown factors regarding the buffer or the memory bus that is worth knowing about that will affect the performance (jitterwise) of the memory bus.
I think you've missed the key word in blackcat's statement: ...reading the data.
It might help if you look at the way Mark Levinson and other top end manufacturers do their DACS and that is to consider that the data is re-clocked at the DAC.
Levinsons also have an excellent description of time/clock jitter, that is worth keeing in mind, essentially that jitter is anything other than exactly 44,100 bits per second, each bit no more and no less than one 44,100th of a second.
It might help if you look at the way Mark Levinson and other top end manufacturers do their DACS and that is to consider that the data is re-clocked at the DAC.
Levinsons also have an excellent description of time/clock jitter, that is worth keeing in mind, essentially that jitter is anything other than exactly 44,100 bits per second, each bit no more and no less than one 44,100th of a second.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.