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! --
Thanks Elias - so if I am understanding correctly, the raw incoming transmission jitter is not actually being eliminated - but rather, the timing accuracy of all the original samples is being re-processed according to the average (mean) accuracy of the incoming clock.
You're very close... Think of the digital audio samples as cars, and the ASRC as a toll booth on a pay highway. The cars will be coming up to the booth at all sorts of different speeds, but they will only leave the toll booth when the gate rises and lets them through.
The booth operator must let the cars through at a very precise, consistent rate (he has a very fancy stop watch). To acheive a consistent (very low jitter) rate, the booth operator averages the rate at which the cars arrived (60 cars arrived during a 600 second period = 1 car per 10 seconds). Even if the first 10 cars arrived within 50 seconds of each other, they will pass through once every 10 seconds - no more, no less.
As you can see, this system is immune to micro fluctuations in arrival time up to a certain threshold. This system can be adjusted to a definitive threshold for macro fluctuations. This is why there is a limit for low-frequency jitter rejection. The limit of the UltraLock system in Benchmark converters is 0.1 Hz. The trade-off for such a low cutoff frequency is longer latency (the amount of time between when the sample arrives and when it is converted).
In other words, the booth operator can increase the amount of time over which his average is calculated so that heavier or lighter times of traffic don't cause fluctuations in his calculations. If he averages over an entire day, rush-hour will not affect his precision, but weekends may throw him off. If he averages over a week, holidays or seasonal travel may throw him off. The larger the time of averaging, the longer the cars have to wait to pass through the booth. Thus, accuracy = latency.
Latency is only a problem for people (typically musicians) who are trying to monitor real-time input. In other words, if a guitar player is recording guitar through an A-to-D converter, then into the computer, then out through the DAC1, the sound of his guitar may be several milliseconds later then when he actually played it (due to the samples filling up buffers before conversion). This may be distracting for the artist performing.
For playback, latency is a non-issue. The latency of the buffers in your computer / transport / etc will far out-weigh the latency of the DAC1. If you can't wait an extra 10 milliseconds to hear jitter-free audio, then perhaps you should replace your espresso with herbal tea.
Originally Posted by G-U-E-S-T
So the incoming stream is being fed into an ASRC process which interpolates and creates almost three times as many new samples, has a continuously varying SRC ratio (according to the variable incoming clock average), and also has its own intrinsic process jitter. Which I believe means, that the entire incoming stream is being ultimately converted into something entirely different, digitally, from what was originally recorded and on the CD/DVD. So while it may or may not sound like what was originally on the CD/DVD, nevertheless the trade-off is that whatever this new post-processed digital stream actually is, at least it can be internally re-clocked and further sent in relatively jitter-free fashion to behave well with the DAC chip - and hopefully the DAC1's analog output stage will then also perform better than the original source. Am I getting this correctly?
EXACTLY!!
To acheive jitter-immunity, the signal must be re-sampled. Therefore, the trade-off is whatever noise and/or distortion is caused by the ASRC. The ASRC used in the DAC1 is the AD1896, so we are talking about -133 dB distortion and 142 dB dynamic range!!! In other words, beyond the threshold of hearing.
The DAC1's analog stage performs one function: condition the analog output of the D-to-A converter to the appropriate voltage and impedance for driving the next device. It is designed to do this with the lowest amount of noise and the least amount of sonic modification as possible.
I just got my dac1 yesterday. It sound great like everyone had said
I notice there are no way to switch off the dac, only the standby mode.
So whenever i wanted to switch it if i just plugged out the power socket. Is that the right way to switch it off? Will it damage my dac in long run?
Hello Chaimingen,
Glad to hear that you're enjoying the DAC1.
Removing the power cable will not damage the DAC1, but it is unnecessary to power it down. It is designed to withstand 24-hr/365-day operation.
This is additional/clarifying data on my problem (ref voice mail to you at 9:00am this am). The problem was very intense last night -- pops and crackles very frequent and very intense. This was good for switching things. Things I could switch easily were players and driver interfaces (cicsplay/ j river and asio4all vs direct sound). Problem was bad on cicsplay/asio4all bad but not as bad with j river/asio4all; problem went away with j river/direct sound. So eureka I thought I found it. This am when I turned on my audio sys there was no signal into the Benchmark at all. It was lost sometime overnight while not playing anything. So I rebooted this am, re inserted usb cables at both ends and got my signal back into the Benchmark (two light came back on). I tried cicsplay/asio4all got pops, tried j river / ds and got one pop. I rebooted again and got j river/ds to play ok for one hour straight. I'm thinking now that because of the overnight phenomena the problem might be the opticis. So later today I will bypass the opticis and go straight from dell -> Benchmark with usb cable (the one that came with the Benchmark, by the way is this a belden?). We'll see what happens. Any comments would be appreciated.
This is additional/clarifying data on my problem (ref voice mail to you at 9:00am this am). The problem was very intense last night -- pops and crackles very frequent and very intense. This was good for switching things. Things I could switch easily were players and driver interfaces (cicsplay/ j river and asio4all vs direct sound). Problem was bad on cicsplay/asio4all bad but not as bad with j river/asio4all; problem went away with j river/direct sound. So eureka I thought I found it. This am when I turned on my audio sys there was no signal into the Benchmark at all. It was lost sometime overnight while not playing anything. So I rebooted this am, re inserted usb cables at both ends and got my signal back into the Benchmark (two light came back on). I tried cicsplay/asio4all got pops, tried j river / ds and got one pop. I rebooted again and got j river/ds to play ok for one hour straight. I'm thinking now that because of the overnight phenomena the problem might be the opticis. So later today I will bypass the opticis and go straight from dell -> Benchmark with usb cable (the one that came with the Benchmark, by the way is this a belden?). We'll see what happens. Any comments would be appreciated.
I would guess that the USB extender is not the culprit. If you are making changes in your software, and it is affecting the performance, then I am very certain that the problem lies internally. There is some software conflict happening with the media app(s) and/or asio4all and/or hardware management software (drivers, etc).
I fixed the hum with a cheater plug---I'm on the same ac circuit as my pc now.
This is never a good idea. I would recommend re-instating the ground pin and using the same outlet that the amplifier is using. You should avoid any ground loops that way.
Ok Elias I have a problem with pops/crackles. I'm using dell xp sp2 cicsplayer -> asio 4all-> opticsis cable-> generic usb cable-> benchmark dac and the sound is fabulous. However I get these pesky pops every now and then (it went away for 3 days after I plugged my mouse/keyboard usbs into the front of the dell leaving my audio usb output all alone except for non used periferalls). I set my latency high in asio4all. Don't know what else to try. Any ideas?
Ted,
I had a similar problem. Yours might be related.
I was planning on using my DAC1PRE with an IBM X22 laptop made in 2003 and running xpsp2. Unfortunately, the system was plagued with pops/crackles and, at high bandwidths, dropouts for several seconds. After going through a litany of driver/port/software/hardware elimination with Elias, no solution was forthcoming and I nearly gave up. After doing some digging around into USB problems, I found software tools to monitor the timing and duration of the computer's interrupts and deferred procedure calls (DPCs, interrupt handlers that get queued to run later when hardware interrupts occur). This way, I was able to isolate the problem to a few devices that were making long-running calls into the kernel. It turned out that ACPI.SYS was the culprit, hanging the machine for unacceptably long time periods -- in interrupt-handling timeframes, which must be very very short -- and (presumably) causing USB packets to be dropped.
ACPI.SYS isn't your garden variety driver, though: It's part of the hardware abstraction layer (HAL) that is installed at a very early phase during a clean OS install. ACPI is the power management system that allows for, among other things, system hibernation and waking upon hardware events like LAN wakeup signals and pressing the power button. There is a technique to turn it off beneath an XP installation, but this is not recommended and the OS should be reinstalled clean. There's a magic keypress to make during the installation of XP that lets you choose the standard HAL instead of accepting the ACPI HAL. I created a new partition on my laptop, then installed XP without the ACPI HAL, and all USB problems have vanished. The power management functions that we're all used to are no longer available, however.
The weird thing about this is that my IBM T23 laptop manufactured exactly one month after the X22 uses the same Intel USB chipset and it works fine with the DAC1PRE!
I should mention that I went through this several months ago. If anyone needs more details, speak up and I'll dig out the nitty gritty and post it here later.
The weird thing about this is that my IBM T23 laptop manufactured exactly one month after the X22 uses the same Intel USB chipset and it works fine with the DAC1PRE!
Apple is going through a spell of this right now. Almost all of their new MacBook and MacBook Pro's are not compatible with most Firewire audio interfaces. No one knows why, and Apple isn't talking about it much.
But the real kick-in-the-pants is that every now and then, one of these computers will work perfectly fine with all firewire audio interfaces!! There doesn't seem to be any reason why the one would work, and so many don't, but...
It just goes to show that no two computers are alike, even if 99.9% of the hardware and software are similar.
BTW, Eric, great job figuring out that power management bug. That was such a deeply burried bug, but you widdled it out! Big thumbs up!!
Also, thanks for offering to help others sort through their computer's issues. Thats what makes the online community so powerful. Hopefully HAL doesn't catch on to Head-Fi!!
Linear Mode
