jesk

24/192 Music Downloads are Very Silly Indeed

Burrows, thank you. All three look interesting, especially the W4S DAC-2 - I like the 2 Toslink RX-Ports.

Dudes, if you dont understand the question then dont answer. Its rather simple. There are many attributes e.g. quality, price, featureset. Everyone has priorities and makes his own decission on them. This question is about that. Its about what would one choose as his individually best matching DAC when considering also the price.

[*]Apogee Digital Ensemble [*]Apogee Rosetta 200 [*]Arcam rDAC [*]Atoll DAC-100 [*]Audio Research DAC7 [*]Aune USB DAC [*]Ayon Skylla [*]Azaly USB-DAC1 [*]B.M.C. DAC [*]Bel Canto DAC 2 [*]Benchmark DAC1 [*]Berkeley Audio Design Alpha DAC [*]Cambridge DacMagic [*]DANGEROUS MUSIC DAC-ST [*]DIGIDESIGN DIGI 003 [*]DIGIDESIGN Eleven [*]DIGIDESIGN MBOX 2 [*]Dugood DAC-3W [*]ECHO AUDIOFIRE 12 [*]ECHO AUDIOFIRE PRE8 [*]EDIROL FA-66 [*]ESI ESU 1808 [*]Eastern Electric Tube DAC [*]Emperical Audio Overdrive DAC [*]FOCUSRITE ISA 428 [*]FOCUSRITE LIQUID SAFFIRE 56 [*]FOCUSRITE SAFFIRE PRO 24 DSP [*]FOCUSRITE SAFFIRE PRO 40 [*]Furutech GT40 USB DAC [*]KONDO KSL-DAC [*]LAKE PEOPLE DAC C460 [*]LEXICON I·ONIX U82S [*]LINE6 TONEPORT UX8 [*]Lavry Black DA11 [*]Lavry DA10 [*]Lite Tube DAC DAC-60 [*]M-AUDIO FAST TRACK ULTRA [*]M-AUDIO FAST TRACK ULTRA 8R [*]M-AUDIO PROFIRE 2626 [*]METRIC HALO MOBILE I/O 2882 EXPANDED [*]MOTU 828 MKIII [*]MOTU 896 MKIII [*]MOTU TRAVELER MKIII [*]MOTU ULTRALITE MKIII HYBRID [*]MUTEC MC-4 [*]Monarchy M24 DAC [*]Music Hall dac25.3 [*]Musical Fidelity V-DAC [*]Mytek Stereo192 [*]Mytek Stereo96 [*]Mytek Studioclock192 CX [*]Naim DAC [*]Northstar DAC Extremo [*]Northstar DAC Model 192 MKII [*]Northstar USB dac32 [*]PHONIC FIREFLY 808 U [*]PRISM SOUND ORPHEUS [*]PS Audio Digital Link III DAC [*]Pacific Valve DAC 72 [*]Pacific Valve Musiland MD-10 [*]RME ADI 192 DD [*]RME ADI-2 [*]RME FIREFACE 400 [*]RME FIREFACE 800 [*]RME FIREFACE UC [*]ROLAND OCTA-CAPTURE [*]SONIC CORE A16 ULTRA [*]SONIFEX REDBOX RB-ADDA [*]STEINBERG MR816 CSX [*]STEINBERG MR816 X [*]Sakura Systems Progression DAC (Model 4705) [*]Sakura Systems Shigaraki DAC (Model 4715) [*]TC ELECTRONIC IMPACT TWIN [*]Tascam HD-P2 [*]The Neko Audio D-100 [*]Violectric DAC-V800 [*]WEISS DAC 202 [*]WEISS MEDEA [*]Wavelentgh Crimson USB DAC [*]Xindak D06 [*]Xindak DAC-5 [*]Xindak DAC-8

Ok Steve, now we understand us. Yes this is the drawback, absolutely. *But* for this to happen the clocks must run out of each other widely. 44.1K/16b means 88.2KBps. Having only a buffer of 200KB would mean beeing able to cache more than 1 second of audio. Until the clocks are ran out of each other with a difference of 1 second all 20 tracks would be played. What also will happen is that after each song the buffer will empty and so over/underrun will not happen. Enough for today. Good night. :-)

> The free running clock that clocks the USB interface in an async > USB implementation. This is a "pull-mode" of transfer. The device > acts as the clcok master and asks the computer for data over > discrete intervals. And does that help to avoid jitter? The answer is no. Because jitter is generated in any case on its way to the final DAC. > All precious implementations of USB audio streaming used Adaptive > mode, which uses some type of PLL to track the incoming data.This > is the "push-mode" of transfer. The device must accept the data > at whatever rate the computer transmits it and synchronize its > clock to this rate. Since the clock is variable and must "lock" > to the incoming rate, it is more jittery by definition. As there are only a few rates to be considered its quite easy to set the clock appropriate. It doesnt need to adjust the rate continuous. After clock-rate is found out, it just needs to get fed with the data out of its buffer in that rate.

Chris, again I'am not saying that jitter isn't important. But cleaning up jitter is just very easy. Stream your data somewhere, find out its rate, buffer it, and then feed it to the DAC. Of course done by a local clock. Clocks are everywhere today. No magic about it. At the moment "vendors" are massively using the hype about the term jitter and its lack of clarity, what it is, why it is and how its solved since years in digital technologies, to make money out of crap. Do you really believe there are no other technologies where you have to feed digital informations into D/A converters to get in exact timing grids stuff happening? Its just everywhere happening. Digital Audio is not different. The difference is maybe that in digital audio streaming over USB/SPDIF/Firewire the sample-rate needs to get analyzed first before having the informations in which rate it needs to get reclocked again. But thats all. Even that could be circumstanced if there would be a protocol around that audio stream like in RTP carrying parameters about its audio payload and so e.g. carrying also its rate. And again, I'am not saying that there are no vendors not just using a buffer+clock+dac in their DAC-units, most of them are doing exactly that. But the hype about Anti-Jitter solutions is just a self-running money machine which has no reason to exist, because solution is simple, already there and widely used.

> Then you dont understand the role of jitter in the D/A conversion. > Asynchronous USB allows a free-running clock to be used as clock > master near the D/A chip. This is the lowest jitter solution. Good explanation. Which free-running clock do you mean and why should that help with jitter? Jitter forms while reading data, transcoding it, mux it, transfering it over the wire/fibre. Much of this happens because of not using realtime OSes and because interfaces/hardware isnt behaving in terms of electricity and attenuation always 100 percent the same. Why should asynchronous transfer-mode in USB help with that? > If you dont believe in jitter, that's another thing entirely. I > wont spend any cycles trying to convince you. Waste of time IME... You didn't read my posts, elsewise you would know that i believe in jitter. I just dont believe in techniques which just exists to get new market segment. Let me guess: you sell that kind of asynch USB stuff?

> Not true. Asynchronous has a broad meaning in digital electronics. > It's unfortunate that they named this mode of USB async. It should > have been called "pull-mode" as opposed to "push-mode". My statement meant that I don't see any reason for asynchronous modes for transmitting audio. I think i explained it enough what asynchronous is about.

Comments inline: > jesk, or whoever you are, asynchronous means "not synchronous". You may have a lot of knowledge of > your field, but it is clear you are not up to speed on the common ways of reducing jitter in digital > audio. Clever statement. Asynchronous means in different technologies different things. So Lets stay in the digital audio world when talking about asynchronous. > In digital audio, the term "asynchronous" is used to describe a data transmission method where > the clock is not determined TO ANY DEGREE be the rate of the incoming data large buffer is used, which > has flow control managed by code, and the output of this buffer is clocked by fixed frequency clocks > (no PLLs or digital synthesized clocks). Partial wrong. Asynchronous means that the sending process isn't locked and can be interrupted. This is possible with userland threading or kernel threading. What asynchronous not automagically should mean is that the receiving end of the communication isn't doing CDR (Clock Data Recovery). This should be done in any case. In neither way of implemention the clocking should be settled by the rate of the incoming data. Imagine a process has to get and send data as accurate as 1/44100 or even 1/192000 a second. Thats not possible because of the lack of a realtime OS and because of involvement of too unprecise physics. Asynchronous communication which is not possible with SPDIF has no benefits for handling jitter. The only thing which can be done with it is keeping the receivers buffer in a well filled state. As soon as the buffer fills too much up or gets empty the receiver can communicate this to the sender so that it can adjust its rate apropriate. PLLs are for nothing more used than for CDR. > By this method the output jitter is generally as low as the inherent jitter in the clock circuit > itself-hence the clock is "not synchronous" in any way with the incoming data. No receiver should adapt to the rate of the incoming signal as its inaccurate. You can do this wrong with both ways of communication - again, not a matter asynchronous or synchronous. > This method of clocking (or re-clocking as in the above examples) is very different than > how digital audio is generally handled by SPDIF input DACs-these use PLLs to adjust the clock to sync > with the rate of the incoming data-typically resulting in jitter levels on an order of magnitude > higher than what can be achieved with asynchronous techniques. Wrong. They just try to adapt to the rate to know if they should interpret that stream as a 1k, 2k, 44k, 88k, 96k or whatever they support rate. Thats the reason why they modulate the data as Biphase-Mark-Code. > I would suggest that you educate yourself on high end digital audio playback before making any more > absolute statements here-it appears that you have a lot of knowledge, which could be shared here. > Streaming audio playback (extremely time sensitive) is very different from ordinary data transfer. No comment.

Barrows, asynchronous means "having controlled connection between two ends" and dont rely on "send and forget". Asynchronous in the case of digital audio is nonsense. Period.

Jesus R, the DAC sends the clock? Sorry but do you understand the basic digital concept at all?

Chris, the whole thing about this story is money.

I don't know. Knowing that means having information from your DACs vendor which state that. But to be honest if it wouldnt use a clock it would sound crappy.

No and yes. An external DAC has a clock or should have at least and it should have Jitter-Buffer. Christian Meutes --- I'am a networker, to me data is just protocol overhead [email protected] - [email protected] - JESK-RIPE