Support Head-Fi.org by
starting all of your
Amazon.com shopping by
clicking here.
____________________________________________________________________
Today's Featured Head-Fi Blog: Jude's Blog
____________________________________________________________________
Please help
support Head-Fi by becoming a Contributing Member
CLICK
HERE -- Contributing Members, thank you
for your generous support! --
in their stock form i like the graces headamp better and the benchmarks dac better. for enjoyment listening. this would go along with their intended purposes. the dac1 is sold as a dac and the grace a headamp.
i do not mean any insult to benchmark. in this hobby we are all looking for a sonic signature each of us find pleasing. it is different for everyone. not everyone ever agrees that one specific amp sounds the best. in the studio the dac1 does exactly the job it is supposed to do. remember, the dac1 was originally designed for engineers. it just so happens that it became popular here as well. those that bash it in any way are looking for a different sonic signature. not finding fault with it as an engineering device. you can hear everything with it and i do mean everything. in that respect job acomplished. most people here consider exagerated and warm to be better. if you are looking for pure resolving accuracy you will spend over $15,000 to do better imo.
Just to clear up what you asked before, the DAC1 circuitry is not transistor based.
Also, the D-to-A chip has a (true) balanced output. This balanced output is then fed into a differential amp. The output is the difference of the + signal and the - signal. You now have a single-ended signal with 6 dB more amplitude and with the common-noise rejected. This single-ended signal is then sent on to the headphone circuitry.
It's been an amazing topic so far, cool that actual 'savants' and designers are willing to put up with the (semi) laymen as well as pro discussion.
One big question is this:
Why use USB at all? I mean sure, if you're building a new computer or using a laptop, perhaps it is worth considering, but personally I have a M-Audio revolution 5.1 card, which I bought specifically for its ASIO/Kernel Streaming options paired with full 192Khz/24b SPDIF output.
Given that someone still has the choice, isnt the SPDIF/AES road the better one?
Additionally, to the Benchmark people in here:
- Could you elaborate on your choice for sticking to upsampling (or downsampling!) to 100-ish Khz instead of going to 192Khz? Were the DAC chips back when you designed it still incapable of reaching 192K safely? By now, the Burr Brown PCM1796 sounds like the better chip. Additionally, modern media like HD-DVD and even DVD-A, SACD are capable of (and I believe sometimes using) the full 24/192/uncompressed, and downsampling hurts.. well somewhat. right? (Shameless plug, I've posted a related question regarding the impact of things like jitter here: Applying science to audiophile voodoo?)
- A lot of companies (unlike yours, it seems) justify the existence of their $23189471239487 DACs by claiming they use better technology, higher quality parts etc. Would you say that your DAC can take the pepsi challenge with 'any conceivable DAC out there' and win (or be equal) when it comes to exact reproduction)? Or are there DACs that outperform yours, if cost would not be a factor at all.
- Given that I don't care for USB (pending your answer on my previous question ), I am planning to use a DAC to drive my system: a -passive- preamp (Adcom GFP-750 - which as I understand it is not much more than an attenuator('resistor') and a few relays) linked to a Bel Canto Evo 4 gen2 (input impedance: 200KOhm) powering Quad 989 speakers. Should this work, or is this not advisable (and if so, why not?)
- One big question regarding Jitter in general.. something that has been burning in my mind for a while: Why don't DACs really buffer? When we are talking about CD players then I can see the need for a 'just in time' solution where instant reaction speeds are important, and error correction needs to make a best guess here-and-now. But for a DAC, why not just buffer 0.3 seconds before starting playback and run the playback off your own clock? If you're scared of noticable buffer sync issues you could allow for a mechanism to sliiightly tweak up or down your clock speed over time if things start to go wrong..
Speaking of Pepsi Challenges, some claim their mods to the benchmark make it a better device. The request for this has been quietly ignored so here it is again: Audioengr: would you be willing to lend Benchmark one of your modded DACs, and Benchmark ppl: would you be willing to compare it to your stock model?
Gents, (m/f)Why use USB at all? I mean sure, if you're building a new computer or using a laptop, perhaps it is worth considering, but personally I have a M-Audio revolution 5.1 card, which I bought specifically for its ASIO/Kernel Streaming options paired with full 192Khz/24b SPDIF output.
Given that someone still has the choice, isnt the SPDIF/AES road the better one?
Speaking of Pepsi Challenges, some claim their mods to the benchmark make it a better device. The request for this has been quietly ignored so here it is again: Audioengr: would you be willing to lend Benchmark one of your modded DACs, and Benchmark ppl: would you be willing to compare it to your stock model?
There are several reasons to use USB:
1) The clock and power system of the computer is a noisy one in most cases, so moving the clock generation and power supply outside the computer is a big advantage to keeping the signals noise-free and the clock low-jitter
2) there are a couple of excellent USB audio chips from TI that have very clever PLL design that can result in much lower jitter than that possible from a Transport. One of these is the TAS1020 that I use and Benchmark uses.
3) S/PDIF is inherently jittery due to the encoding of clock and data into one signal and recovery of the clock and data at the receiver chip. There is usually another PLL involved in this decoding. If you can avoid this encoding/decoding process, it is a big win.
4) S/PDIF inherently has cable length limitations because the cable contributes to the jitter significantly and directly. USB cable has less effect on the jitter due to the excellent PLL at the USB converter (assuming that a low-jitter clock is driving the chip).
As for the shoot-out, I'm all for it, however it should be performed by a 3rd party, not by Benchmark or myself. The 3rd party should have a sufficiently resolving full-range system (not a sub-satellite for instance).
When I think about it, this has already been done by several of my customers that have multiple DAC-1's. They get one modded and then compare it to their stock unit:
These of course are anecdotal only. Unless I actually hear the system that will be used for the shoot-out proposed, I do not trust it to be good enough. I have found that even many reviewers systems are sub-par and very colored.
Scenerio 1
As for buffering serial data in DAC's, this is not as easy as it might seem. If there is a master clock in the DAC and this clock can be driven back to the source, which is a slave device and uses this clock, then the design can be straightforward. Some expensive and professional DAC's do this, usually with a word-clock driven back to a transport. There is no PLL required to clock the FIFO output in this type of design, so it can be extremely low-jitter.
Scenerio 2
If the source clock cannot come from the DAC, such as a computer driving USB, then the receiving device must lock onto the arriving PC-generated clock using some type of PLL. The DAC cannot be the source of the clock (assuming no upsampling). If the DAC clock tracks the PC clock, then the FIFO memory in the DAC will not overrun or underrun. The PLL makes sure that the outgoing clock from the FIFO is closely matched to the PC clock. The problem is that the PLL adds it's own jitter, and can never be completely independent of the PC clock.
One instance where Scenerio 1 can be implemented for computer audio is the network case. If ethernet protocol is used, either wirelessly or wired, then the clock at the receiving device becomes the source clock. This clock can be generated without PLL's and a FIFO data buffer can be used. This is something that I'm doing with the Squeezebox3 and my Pace-Car FIFO reclocker.
Scenerio 1 might also be implemented with a PCI audio card with a master clock on it. If the master clock were driven from the DAC, then this would work well also. The master clock would have to be implemented in the DAC.
1) The clock and power system of the computer is a noisy one in most cases, so moving the clock generation and power supply outside the computer is a big advantage to keeping the signals noise-free and the clock low-jitter
2) there are a couple of excellent USB audio chips from TI that have very clever PLL design that can result in much lower jitter than that possible from a Transport. One of these is the TAS1020 that I use and Benchmark uses.
3) S/PDIF is inherently jittery due to the encoding of clock and data into one signal and recovery of the clock and data at the receiver chip. There is usually another PLL involved in this decoding. If you can avoid this encoding/decoding process, it is a big win.
4) S/PDIF inherently has cable length limitations because the cable contributes to the jitter significantly and directly. USB cable has less effect on the jitter due to the excellent PLL at the USB converter (assuming that a low-jitter clock is driving the chip).
Curious, I was under the impression that the way USB was designed was mostly with data bursts in mind (i.e. lots of priority and scheduling stuff that was hard to control). Also, I think Im misunderstanding you cause you say it is bad that the clock is at the computer (noise by fans/hdds) but also that the USB system has the dac here.
Anyway, with for example the benchmark dac1, the effects of jitter should be 'solved' right?
As for the shoot-out, I'm all for it, however it should be performed by a 3rd party, not by Benchmark or myself.
Benchmark sounds like a fine party to me, since they will sell one DAC for each buy, modded or not. They have little to lose here (other than time) since you will have to buy a DAC from them first, before you can mod.
The 3rd party should have a sufficiently resolving full-range system (not a sub-satellite for instance).
These of course are anecdotal only. Unless I actually hear the system that will be used for the shoot-out proposed, I do not trust it to be good enough. I have found that even many reviewers systems are sub-par and very colored.
Hey, send me your modded dac, I plan to audition multiple dacs soon since my old one - (Philips IS 5022) blew up
I've built my stereo with accurate reproduction in mind.
* Benchmark DAC1 (not sure if I want USB or non-USB) ($1000)
+ Good price
+ Excellent anti jitter
- Samples everything to 100ish Khz (even 192Khz DVD-A sources )
- Upsampling can't be turned off
* Bel Canto DAC3 ($2500)
+ Resamples to 192Khz
+ Has the same UltraLock anti jitter as the Benchmark
+ Better input stages than Benchmark
+/- More modern DAC (BB 1792's).. Potentially better
+/- Possibly handles 192Khz sources without resampling.. not sure, docs are fuzzy
- Price ($2500)
- Resampling can't be turned off
* AQVox USB 2 D/A MKII ($1000)
+ Resamples to 192Khz or 'bypass' (no resampling)
+ Handles 192Khz sources
+/- BB 1796 DAC's, which are inferior to the Bel Canto's, but possibly better than Benchmark
- Less documentation on jitter compensation, probably inferior to DAC1/DAC3
- Possibly inferior output stage... might become an issue with passive pre-amp.
As you can tell, this '192Khz source support' is an issue for me.. modern sources (DVD-A, SACD (in a way, it doesnt use PCM), HD-DVD and BlueRay) all support 192/24bit, so buying something that does less puts you a bit behind the times from the get go.
Scenerio 1
As for buffering serial data in DAC's, this is not as easy as it might seem. If there is a master clock in the DAC and this clock can be driven back to the source, which is a slave device and uses this clock, then the design can be straightforward. Some expensive and professional DAC's do this, usually with a word-clock driven back to a transport. There is no PLL required to clock the FIFO output in this type of design, so it can be extremely low-jitter.
Scenerio 2
If the source clock cannot come from the DAC, such as a computer driving USB, then the receiving device must lock onto the arriving PC-generated clock using some type of PLL. The DAC cannot be the source of the clock (assuming no upsampling). If the DAC clock tracks the PC clock, then the FIFO memory in the DAC will not overrun or underrun. The PLL makes sure that the outgoing clock from the FIFO is closely matched to the PC clock. The problem is that the PLL adds it's own jitter, and can never be completely independent of the PC clock.
One instance where Scenerio 1 can be implemented for computer audio is the network case. If ethernet protocol is used, either wirelessly or wired, then the clock at the receiving device becomes the source clock. This clock can be generated without PLL's and a FIFO data buffer can be used. This is something that I'm doing with the Squeezebox3 and my Pace-Car FIFO reclocker.
Scenerio 1 might also be implemented with a PCI audio card with a master clock on it. If the master clock were driven from the DAC, then this would work well also. The master clock would have to be implemented in the DAC.
Steve N.
Makes sense, mostly, although well.. Im sure it is still a touchy subject and benchmark/belcanto claim the issue of jitter is moot if you use their products.. Also, again you go for the 'clock' route, where I was suggesting 'better buffering by reading ahead at more than 1x speed'
Curious, I was under the impression that the way USB was designed was mostly with data bursts in mind (i.e. lots of priority and scheduling stuff that was hard to control). Also, I think Im misunderstanding you cause you say it is bad that the clock is at the computer (noise by fans/hdds) but also that the USB system has the dac here.
Anyway, with for example the benchmark dac1, the effects of jitter should be 'solved' right?
USB has several modes of operation that have different protocols: Asynchronous, Block/Burst and Isochronous (AKA Synchronous Adaptive). Printers use a different protocol than streaming audio. Early development by TI set the stage for streaming audio, when they tried different protocols and decided that Synchronous Adaptive was the best performer with the least probability of drop-outs. Thier chips are designed around this protocol, although others can be implemented with some chips. Most USB adapters work this way.
As for the jitter in a stock DAC-1, this is addressed in their design by using asynchronous upsampling like many other DAC's. It certainly does reduce the jitter of the incoming stream, probably better than many DAC's.
However, this technique does not totally eliminate jitter IME. When I remove the upsampling chip and replace it with an I2S interface driven by my FIFO reclocker, the audible jitter is noticable lower.
As you can tell, this '192Khz source support' is an issue for me.. modern sources (DVD-A, SACD (in a way, it doesnt use PCM), HD-DVD and BlueRay) all support 192/24bit, so buying something that does less puts you a bit behind the times from the get go.
When cosidering the human's hearing capability, the only benefit of higher sample rates is to be able to user larger ranges for filtering cutoffs, preventing aliasing more easily and so on. The sampling itself is lossless in theory as long as frequency input is limited and thus complies with the theorem.
So, upsampling to 192 kHz or oversampling in general maybe makes conversation easier to implement and increases the quality. Otherwise, Benchmark claimes that exactly this performance would be better when using about 110 kHz instead of 192 kHz, even if some analog bandwidth will be lost this way. But hey, we dont' hear it anyway and ultrasonic influences have never be proven so far. I doubt you would hear any diferrence, but perhaps you will feel better, knowing that the music arrives to you in its original sample rate.
As you can tell, this '192Khz source support' is an issue for me.. modern sources (DVD-A, SACD (in a way, it doesnt use PCM), HD-DVD and BlueRay) all support 192/24bit, so buying something that does less puts you a bit behind the times from the get go.
how can any of this formats be fed into stereo dac, w/ 192Khz support or not? am i missing something?
When considering the human's hearing capability, the only benefit of higher sample rates is to be able to user larger ranges for filtering cutoffs, preventing aliasing more easily and so on. The sampling itself is lossless in theory as long as frequency input is limited and thus complies with the theorem.
I do not agree. Higher sample rates do sound more like analog to me. Believe it or not, even vocalists sound much more smooth and natural with upsampling to 24/96. 24/192 is even a skosh better than that IMO. The upsampler must use a good algorithm though. Not all upsampling chips are equal. Likewise, computer upsampling codes all sound different, with a few exceptional ones. I find the original SRC code to 24/96 to be exceptionally good, and so do the reviewers that have reviewed my products. They all listen to the 16/44.1 and then the upsampled to 24/96 and never go back to the 16/44.1 again.
S/PDIF is inherently jittery due to the encoding of clock and data into one signal and recovery of the clock and data at the receiver chip. There is usually another PLL involved in this decoding.
In asynchronous isochronous mode USB Audio has no jitter issue whatsoever, since USB clocking has nothing to do with the audio clock. Jitter's only effect then could be data corruption, and that takes a lot of jitter, though it can be an issue since USB Audio has no error correction, and error rates on some Windows systems tend to be high.
If the source clock cannot come from the DAC, such as a computer driving USB, then the receiving device must lock onto the arriving PC-generated clock using some type of PLL. The DAC cannot be the source of the clock (assuming no upsampling).
Asynchronous isocrhonous USB Audio mode is computer driven, but the DAC provides flow control, thus the audio clocking is entirely up to the DAC. Therefore, your statement is false. Indeed, Wavelength who's another head-fi member builds and sells USB DACs that support the asynchronous USB mode and thus have no interface jitter without resampling, so it's just a matter of implementing the standard in the firmware of the USB controller being used.
One instance where Scenerio 1 can be implemented for computer audio is the network case.
Why bother, when you can do that with USB? The USB Audio standard has supported asynchronous isocrhonous mode from the beginning!
Originally Posted by puntloos
Hey Steve, thanks for the reply so far.
Curious, I was under the impression that the way USB was designed was mostly with data bursts in mind (i.e. lots of priority and scheduling stuff that was hard to control).
USB has other modes, such as bulk transfer, which support error correction, but lack streaming ability with guaranteed throughput to prevent underruns in cases of high system load.
DACs currently on my list:
I was going to recommend Wavelength's DACs because they eliminate jitter by using asynchronous modes, but then I noticed it's a non-oversampling DAC... Nooo... it's like getting one part perfect, and another one completely backwards... ;_;
Originally Posted by audioengr
USB has several modes of operation that have different protocols: Asynchronous, Block/Burst and Isochronous (AKA Synchronous Adaptive).
Uh, you mixed them up here. Block and burst modes are standard data transfer modes for non-audio. USB Audio uses isochronous mode in one of three submodes, which are either synchronous, adaptive, or asynchronous.
__________________
Chat with us live at #diyaudio on irc.rizon.net !
"Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." -Plato
), I am planning to use a DAC to drive my system: a -passive- preamp (Adcom GFP-750 - which as I understand it is not much more than an attenuator('resistor') and a few relays) linked to a Bel Canto Evo 4 gen2 (input impedance: 200KOhm) powering Quad 989 speakers. Should this work, or is this not advisable (and if so, why not?)
