Jump to content

TheZephyr

  • Posts

    16
  • Joined

  • Last visited

  • Country

    country-ZZ

Retained

  • Member Title
    Newbie
  1. Does anybody out there use a software real time analyzer for room tuning, speaker placement, etc? It must be Windows based, I don't care if this means that I am a moron or that a Mac version is a billion times better, it must be Windows based. I would also appreciate recommendations for a microphone for use in conjunction.
  2. Clearly nothing is more important than individual satisfaction with the sound of the DAC. The fact that a DAC uses a buffer (together with asynch) to eliminate sensitivity to external jitter allows one to select a sensible cable and be confident that if it passes transparency then there is no gain (other than placebo) to be had by fiddling with and investing in high end firewire cables. In my case a very inexpensive cable that is twice as long as the firewire spec allows to begin with works perfectly. This allows me to tap into an HTPC in another room and avoid having to locate a PC in the listening room, and that even though the cable is cheap and long there is no possibility in this case that cable effects such as jitter are interfering with the sound. This is a win-win for me and will be for others as well and is the original point of this thread. I definately agree that there are a lot of armchair engineers out there.
  3. 'There is no industry standard written down of what the term "asynchronous" means (please correct me if I'm wrong).' There is no confusion on this subject amongst engineers. Clearly there is a great deal of confusion amongst non enigneers, perhaps induced by creative advertising.
  4. 'Chord (with their buffer) did claim their DAC64 was transport independent (and I guess by extension cable independent). But they then went and produced their own high end transport. Having said that Weiss said that digital volume was perfect then produced a high end TVC passive "pre-amp".' Because they want to make more money.
  5. "Clay commented... In multiple instances, Daniel refers to use of PLLs to accommodate for use of a single fixed frequency oscillator in direct contrast to what Gordon (and others, e.g. Barrows, Bob Stern, et al) feel is a requirement for being considered a "truly" Asynchronous interface, specifically, the use of dual fixed frequency oscillators - one for 44.1kHz & multiples and another for 48kHz and multiples." The use of multile oscillators is not required for asynch. Control signals, rather than time, gate in the input signal. The origin of the clock signal used by the DAC chip is internal and is in no way dependant on or derived from the music data arriving from the source over the digital interface. So you have bits coming in over the digital interface at one rate and bits being used by the DAC chip at another. To accomodate this difference in rates you need a buffer. One process fills the buffer in bursts at one rate and another process empties it at another rate. That is the essense of the implementation (definition) of an asynchronous interface. I believe the confusion is based on the failure to understand that the PLL is used to derive clock signals of different rates and the incorrect belief that the PLL is used to lock on to the digital input signal such as is regularly done for FM radio or toslink digital.
  6. Perhaps there is something to Mpingo disks after all. Two years ago I went to Machu Picchu and I sat my Zune down on the chair at the center of the convergance zone. I swear, from that moment on, there was a dramatic expansion of the sound stage and increased complexity of the timbral hues in the upper mide-bass. :-P
  7. Ah yes, listening tests which contradict simple principles of physics and engineering. Ever heard of the Mpingo Disc or the green pen? Perhaps the engineers who design things do not understand that which they are designing? What are the odds that if they did not understand what they are doing that they would be able to make these devices function to begin with? Buffering is a very widely applied principle in engineering and broader sciences in general. One type of application of buffering is to decouple time related influence from the input process and make sure that the output process is never starved. It is well understood and if implemented correctly it works correctly, it is physically impossible to recall any time related input information because it does not exist. If it does not exist then you cannot hear it. Are you asserting that time related information from the input process to the buffer is somehow preserved through the output process from the buffer?
  8. "As you are perhaps aware, Zephyr's view is a common misconception, esp. for those arriving here at CA with computer/software backgrounds." Zephyr is not suffering from a misconception, he knows exactly what he is talking about. Perhaps there is a misconception about how the PLL is used and how the buffer is used in the specific case cited. Perhaps an analogy would be of assistance. Consider the creation of a digital document; the amount of time required to create the document has no bearing on how long it takes to read the document or individual objects in the document. There is no timing information stored in the document, it does not exist, and therfore is unable to influence the reading process. And Zephyr did not suggest that cables do not influence other (non buffered) input designs.
  9. If I were to design a USB DAC today (and I actually did design and build a DAC before the CD was on the market) I would definately implement a jitter free input buffer. I do not know whether or not any of the current crop do this, I have not researched the market. I agree that there should be no difference in input performance at all between properly designed buffered systems.
  10. Ok, so I got a response from the man Daniel Weiss himself and the 202 firewire interface is truly asynchronous. It reads blocks of data from the source into a buffer and then reads the words out of the buffer into the D/A converter clocked by the 202's internal clock. Since the buffer does not maintain any jitter information, all the jitter information is lost, and the DAC is immune to jitter on that interface. If the cable is able to pass the transparency test (not drop bits) then it is functionaly eqivalent to any other cable which can also pass the transparency test. [snark]If you can hear differences of firewire cables on this DAC then you can probably also hear differences in music bits stored on different brands of hard drive on the source computer.[/snark]
  11. "I only responded to correct the common misconception (esp. among computer engineers) that Asynchronous interfaces eliminate the possibility for cables, or computers, to impact the sound. No one really knows why yet, but even with Async interfaces, both can make a difference." Thanks :-)
  12. "Given the DAC202's lack of fixed rate oscillators for each frequency set (one for 44.1 & multiples and another for 48k & multiples), and it's concommitant use of PLLs for syncing of clocks (rather than reliance on a fixed rate oscillator in the DAC as master clock which is a hallmark of truly asynchronous devices), it is debatable whether it should be considered asynchronous." It has an internal clock for use with the firewire interface, it does not use a PLL for that interface. "There's also another flaw in your assumption that Asynchronous devices are immune to jitter from ca ble, esp, that asynchronous USB devices remain quite cable dependent." So are you saying that a device which fills a buffer in bursts and then empties it by a clock will conserve the information of input jitter in the buffer? "Perhaps your DAC is immune to jitter (aren't they all claimed to be?), but claiming immunity by dint of an Asynchronous transmission is suspect." Perhaps I am not familiar with all the details of implementation of the DAC 202, and perhaps I am misinformed about the implementation being asynchronous (I will send an email to Mr. Weiss to find out). But I am an actual computer engineer, and I am quite certain that a buffer will not preserve jitter unless it is specifically designed to do so.
  13. "Anyway, have you tried different cables or are just just dismissing differences based on reason?" Yes, the audiophile in me enjoys all manner testing and tweeking. I have spent time and money on interconnects and noticed huge differences there and ended up with some fairly exotic cables. I have side by side home auditioned sets of speaker cables worth $6k and found a $60 pair as having the best sound. For firewire I obtained a short length of a high end cable just to be sure the DAC would be usable as soon as I got it home. I set up the source computer next to the DAC for a short while. I could perceive no difference in sound between the 'nice' cable and the cheapo on my very revealing system. Just as I believe that in some scenarios people are imagining improvements which do not exist, I realize that I may not have noticed improvements that did exist, so my listening test does not prove anything. That said, the logic of the asynchronous connection in conjunction with my listening experience leads me to understand that for the specific case of the Weiss DAC 202 (and very likey other asynch capable devices) which is immune to cable/source jitter over firewire, a high end cable gives no benefit beyond that offered by a basic fully functional cable. No doubt cables do have much influence on some other equipment. Even devices like USB printers can be rendered unusable by poor cable.
  14. I have seen the numerous threads on this site, I understand the nature of the debate. What may not be understood by some is the nature of an asynchronous connection. In an asynchronous connection the sink receives data in chuncks, not in a stream, and plays them at it's own rate. Much like filling up a gas tank and then emptying it by driving, the jitter of the gas pump has no influence on the driving performance. Jitter of the cable in this case is 100% irrellevant, to hear the influence of the cable in this case is to have an active imagination.
×
×
  • Create New...