Asynkron DAC?

[Bjørn ("Orso")]

Som Man skriver så bruker den nevnte Music Serveren kun Lynx kort til å sende digitalt ut og en annen enhet til D/A konvertering. Det er viktig å påpeke.

Om det har noe for seg om bruke et Lynx kort til 6k framfor f.eks noe til 1-2k når man bruker digitalt ut, er dog et spørsmål jeg stiller meg. At Lynx AES16 veldig ofte anbefales til dette bruket trenger ikke å ha en annen sammenheng enn at handler mye om være på den trygge siden og fordi Lynx har et godt rykte på seg. Eller noen som vet noe annet?

 

[nistad]

Litt dybdeinfo far Kevin Halverson-HRT om hva de tenker/gjør:

The Music Streamer II as well as the Music Streamer products, use a TI TAS1020B running our own firmware for their USB PHY/Transceiver section. Calling it a receiver isn't technically correct as there is data coming from the host to our device as well as data from our device to the host. In USB protocol these are IN and OUT Endpoints and the bi-directional transactions make this section of our product a transceiver (transmitter / receiver hybrid).

In the case of all the products, they utilize an asynchronous transfer protocol in order to eliminate any interface jitter as our technique produces the master clock locally within our device and the host
(computer) is slaved to our clock. This is a vastly superior interface compared to any bi-phase clock recovery system such as S/PDIF or any of the other USB protocols.


Asynchronous transfer protocol. For detailed reading on the subject, I would recommend the USB forum's paper entitled "Universal Serial Bus Device Class Definition for Audio Devices" which is available at:

http://www.usb.org/developers/devclass_docs/audio10.pdf

In direct reply to the question"...but how this new master clock can control a computer's bus timing..." This misunderstanding is what needs to be corrected. The device (Streamer) does not control the host's
(computer's) bus timing, the computer runs completely independently of the Streamer. What is controlled is the size of the data packets that the host (computer) sends to the device (Streamer).

The term asynchronous (or 'not' synchronous) defines that neither the clock within the host (computer) nor within the device (Streamer in this
case) are synchronized at all. Both are free running and while they may be close in terms of frequency (or just as easily may not be very close), there is no fundamental control of either over the other. The clock generated by the host is typically a very poor one as it is subject to many sources of modulation from both hardware and software constraints. Using it in any way virtually guarantees large levels of jitter. The asynchronous approach allows both ends to operate independently and via a communication mechanism the device (Streamer) is polled by the host on a predetermined interval for a 'feedback' value that the device calculates and supplies to the host. The host then modifies its data payload and sends either more or less samples in subsequent data packet(s). This allows the data rate on average to match yet frees the device from the poor clock performance of the host.
The actual mechanism for calculating and supplying this feedback data to the host (and handling errors of the host) is very complex and well beyond what can be conveyed in a limited amount of space (and time) but the concept is, at the surface level, very easy to understand.

Let me give you an example.

Say that the host clock is intended to be supplying audio at 44,100 Hz (CD data rate) but due to its very poor nature is actually running at and average frequency of 44,099 Hz. In this same example, the device is generating an accurate, and more importantly low jitter, clock that is exactly 44,100 Hz for driving its audio circuits. This 1 Hz difference would quickly cause the two ends to drift apart and the data packets would become corrupt and a complete loss of function would result.
Since the data comes in packets and the number of audio samples in the packet is under control of the software, the device sends to the host (in response to a request from the host) a value that describes the difference between the two data rates. This information that defines the difference is called the feedback value. In this example, the hosts clock is .0022676% slower than it should be; and after a matter of just a few thousand frames, the two ends would be hopelessly apart and the result would be something that would be described to as completely random noise, not audio.

In a streaming audio application the data is sent in packets that arrive once ever millisecond (1/1000 of a second or 1000 data packets per second). Each packet would need to contain 44.1 samples, but only whole samples can be sent, so the host will send 44 samples for 9 frames (a total of 396 samples) and then on the 10th frame, it will send 45 samples. This makes a total of 441 samples in 10 frames and then the process is repeated during the next 10 frames. Since in my example the host is running slower than it should, eventually, the device's buffer would underflow (run out of data) and the whole system would crash, but with the device calculating the error of the host, it can request that one data packet have an additional sample to keep the two ends in relative synchronization but still allowing their clocks to run completely independently. As long as the buffer neither underflows (runs out of data) nor overflows (runs out of space), then the system works perfectly.

For a situation where the host is running faster than the device, the device sends feedback data that reduces the number of samples in the occasional frame. Again, the system stays intact via the feedback mechanism.

Consider the situation where the host generates a very poor clock interval (due to task handling, hardware design or as is nearly always the case, a combination of both) and each sample arrives either on time, early or late, this is exactly what happens and the result is classic jitter. Since the device (Streamer) is independent of this, there is zero impact on the conversion performance since our device operates only from its own locally generated clock. The difference in jitter levels is typically (with most computers) a factor from 100 to 1000 times lower for an asynchronous approach when contrasted to any of the other protocols available to an audio streaming (isochronous or constant
interval) task.

Hopefully, this brief explanation affords one adequate information to understand how an asynchronous transfer protocol system can be completely independent of jitter which would otherwise result for any computer sourced audio application. What should be obvious is that S/PDIF is also subject to this same poor clock performance of the host
(computer) as there is no feedback mechanism and the device must extract the clock from the data itself (which adds even more jitter). Compared to asynchronous USB, S/PDIF can be tens of thousands times lower performance and by contrast, makes it a very poor choice for anything even approaching high performance audio.

Kevin Halverson-HRT

 

[Parelius]

Dette ble i det minste litt forståelig for meg - tror jeg.

Det jeg ikke forstår er hva som skjer når S/PDIF kommer inn i bildet. Jeg har tidligere vært av den oppfatning at «SPDIF is a synchronous protocol», og noe av det samme blir sagt av Kevin Halverson på slutten. Ved bruke av min HiFace (USB til S/PDIF) så får en altså ikke en asynkron DAC bare ved hjelp av dette.

På den andre side, så forstår jeg RoDa slik at det er nettopp det han kaller asynkron USB, og som har gitt ham troen på PC-lyd:

Er det hørbart og er dette snake-oil/ekstremteori.....

Det er i alle fall målbart, men man kan alltids diskutere om jitterverdiene uansett er under der som regnes som hørbart, og det blir det neppe noen gang enighet om... som sagt var det ingen som klagde på USB-DACer før noen oppdaget at det var noe som het asynkron USB.

Tull og vas!

Jeg er en av de som har ment at pc-lyd har vært noe grå og livløs sammenlignet med cd-drivverk.
Jeg har ikke forstått hvorfor, og fått høre den vanlige "null er null, og en er en".....

Men da jeg fikk høre forskjellen på adaptiv kontra asynkron USB til SPDIF, så ble jeg glad!
Endelig hørte jeg noe som gjorde at jeg fikk trua på pc-lyd.
Kan ikke er dritt om det tekniske, og må spørre meg frem for å kjøpe en USB til SPDIF konverter som er teknisk "rett".

Enten er det noe jeg ikke forstår – siden jeg ikke helt ser hvordan dette henger sammen – eller så er RoDas utsagn - om jeg nå forstår ham rett - bare et eksempel på hva nb kaller buzzword (om det nå var det han brukte).

 

[Nordenstam]

[flisespikk]
[/flisespikk]

He he.. Skjønner at dette er litt flisespikking fra min side, men det er da engang sånn det er..

Mente at det var jeg som bedrev flisespikk!

Håper det ikke forvirret noen. Var en rent språklig diskurs, har ingenting med teknisk prestanda å gjøre.

Når Computeraudiophile velger å sette kortet på listen over anbefalte komponenter til avspilling så kan man regne med at det er et godt alternativ. Du finner det på Cash-siden deres, der det er mulig å velge fra mange ulike hyller. Såvidt jeg kan se deres dyreste alternativ i kategorien.

Blir litt skeptisk når de plasserer et slikt Lynx kort på en liste over "lydkort". Lynx AES16 er et grensesnitt med utelukkende digitale inn og utganger. For å få hørbar lyd ut av kortet må det brukes en ekstern DAC. RME har et tilsvarende kort som heter AES32.

Det neste kortet som nevnt på listen, RME9632, er et multiformat grensesnitt som har både 8 kanals ADAT lightpipe, SPDIF IO og analog inn/ut. Med ekspansjonskort til sammen maks 16(32) kanaler i sving. Derav 9632 navnet. Er mye av pengene for et slikt kort som går til andre funksjoner enn selve D->A konverteringen. DAC'ene er sikkert ganske fin de, men det burde være mulig å få mer for pengene om det kun er grensesnitt mot PC og en tokanals DAC som er målet.


Elllers, når det gjelder tråden her, håper jeg ikke folk ser seg blind på ett enkelt teknisk aspekt. Selv om en grunnteknologi kan være en god idé i seg selv er det ingen automatikk i at alle bokser med en slik teknologi får bedre prestanda enn andre bokser.

 

[Parelius]

Elllers, når det gjelder tråden her, håper jeg ikke folk ser seg blind på ett enkelt teknisk aspekt. Selv om en grunnteknologi kan være en god idé i seg selv er det ingen automatikk i at alle bokser med en slik teknologi får bedre prestanda enn andre bokser.

Det er vel det som er problemet med buzzwords…

Takk for lærerike innlegg, forresten.

 

[nma]

Dette ble i det minste litt forståelig for meg - tror jeg.

Det jeg ikke forstår er hva som skjer når S/PDIF kommer inn i bildet. Jeg har tidligere vært av den oppfatning at «SPDIF is a synchronous protocol», og noe av det samme blir sagt av Kevin Halverson på slutten. Ved bruke av min HiFace (USB til S/PDIF) så får en altså ikke en asynkron DAC bare ved hjelp av dette.

På den andre side, så forstår jeg RoDa slik at det er nettopp det han kaller asynkron USB, og som har gitt ham troen på PC-lyd:



Enten er det noe jeg ikke forstår – siden jeg ikke helt ser hvordan dette henger sammen – eller så er RoDas utsagn - om jeg nå forstår ham rett - bare et eksempel på hva nb kaller buzzword (om det nå var det han brukte).

Asynkron USB brukes for å få et best mulig S/Pdif signal ut. Er ikke verre enn det.

 

[Parelius]

Dette ble i det minste litt forståelig for meg - tror jeg.

Det jeg ikke forstår er hva som skjer når S/PDIF kommer inn i bildet. Jeg har tidligere vært av den oppfatning at «SPDIF is a synchronous protocol», og noe av det samme blir sagt av Kevin Halverson på slutten. Ved bruke av min HiFace (USB til S/PDIF) så får en altså ikke en asynkron DAC bare ved hjelp av dette.

På den andre side, så forstår jeg RoDa slik at det er nettopp det han kaller asynkron USB, og som har gitt ham troen på PC-lyd:



Enten er det noe jeg ikke forstår – siden jeg ikke helt ser hvordan dette henger sammen – eller så er RoDas utsagn - om jeg nå forstår ham rett - bare et eksempel på hva nb kaller buzzword (om det nå var det han brukte).

Asynkron USB brukes for å få et best mulig S/Pdif signal ut. Er ikke verre enn det.

Så langt er jeg med. Men fra det grensesnittet er det adaptivt inn i DACen.

Akkurat den funksjonen er det vel HiFace har, om jeg har forstått det rett. For meg er det ingen forskjell med eller uten HiFace i anlegget, men jeg er en gammel mann med god DAC.

 

[nb]

Elllers, når det gjelder tråden her, håper jeg ikke folk ser seg blind på ett enkelt teknisk aspekt. Selv om en grunnteknologi kan være en god idé i seg selv er det ingen automatikk i at alle bokser med en slik teknologi får bedre prestanda enn andre bokser.

Presis. Det er underlig at noe som normalt er mest opptatt av "føleri" (HiFi) har blitt så teknologifokusert på akkurat dette ene punktet. "Er den asynkron" er jo tydligvis det som det lures mest på nå, det pleier å være hvordan den låter, som normalt ikke pleier å være veldig korrelert med hvilken teknologisk løsning som er valgt for å lage en dings eller hvilke grensesnitt som er valgt.

 

[KW]

The key consideration for any external DAC is how to minimize or eliminate jitter. We've seen analog Phase Locked Loops (PLLs), digital PLLs and RAM buffers. Ed Meitner discards all of these methods in favor of his new MFAST (Meitner Frequency Acquisition System) technology, an asynchronous method which simply discards the clock embedded in the original signal. I asked EMM Labs' Shahin Al Rashid to explain:

"There are several types of asynchronous data communications techniques and what we do in the so-called 'MFAST' receiver is a specific high-speed method. Roughly speaking, we dump all the incoming bits into an elastic buffer and read them out with a stable clock, free from source jitter. The artful part is in how to avoid buffer overrun (bits will be lost) or underrun (not enough bits mean dropouts). The method is entirely digital and performed by programmable circuits within one of the three Xilinx gate arrays."

Kanskje man kan komme ned på minimum (eventuelt langt under det hørbare) på andre måter også.
Ikke vet jeg og ikke finner jeg noe data om jittermengde på min Dac2 noe sted heller og ikke vet jeg hvordan det høres ut heller i den grad jeg eventuelt skulle evne å høre slikt.

Hvilke produsenter oppgir data/specs om jitter på sine produkter i sine egne specs, jeg vet jo at det måles ved (enkelte?) tester i Stereophile, har Stereophile slikt måleutsyr så ville jeg tro at også produsenter av dacer har det, ikke minst nå siden det nå er blitt så populært å bruke det i en del sammenheng.
Og i hvilken grad benyttes direkte sammenlignbare specs fra de som eventuelt oppgir slike data.

Samt at jitter vel er et uttrykk som spenner over flere områder, slik at det kanskje kan være fort gjort å blande her :

Noen som har sett jitter verdier for min EmmLabs dac 2, kjekt å vite så jeg vet om jeg må ha ny dac eller ikke ;D

Kan jo nærmest få inntrykk av at bare en hvilken som helst dac har USB asynkron, så spiller det bedre enn alt annet uten asynkron :


Skyt om ønskelig "EMM Labs' Shahin Al Rashid" ikke meg om vedkommende har kommet med uttalelser som ikke holder mål ;D
Mvh.KW

 

[Parelius]

Litt på siden kanskje, men likevel. Tidligere oppgraderte en jo gjerne CDP med en ekstra innstallert klokke (LClock var vel i vinden?). Slike kan vel installeres i eksterne DACer også vil jeg tro (- eller er jeg på bærtur her?)

Hypotetisk tenkt: Gitt at asynkrone DACer er SOTA, hvilken fordeler har disse i forhold til DACer med f.eks. en LClock? Oppnår en ikke «det samme»?

 

[KW]

Litt på siden kanskje, men likevel. Tidligere oppgraderte en jo gjerne CDP med en ekstra innstallert klokke (LClock var vel i vinden?). Slike kan vel installeres i eksterne DACer også vil jeg tro (- eller er jeg på bærtur her?)

Hypotetisk tenkt: Gitt at asynkrone DACer er SOTA, hvilken fordeler har disse i forhold til DACer med f.eks. en LClock? Oppnår en ikke «det samme»?

Nei, det tror jeg ikke (sier tror )
Det er vel bare kvalitetsforskjeller (nøyaktighet) på klokker det er snakk om, spørs om ikke det (også?) er snakk om markedsføring alternativt mikromessige måleforskjeller mer enn reelt hørbart (for slike som oss : )
Har for en liten tid tilbake vært med på en test/demo av 2/3 forskjellige klokker (den tredje var kanskje ikke ren klokke helt på samme måte som de 2 andre fordi Atomklokka (som den ble kallt måtte brukes sammen med ei klokke........................hørte ikke forskjell jeg mellom de to/tre nevnte.

Under seansen så skjedde det noe som gjør at jeg nok blir mer overbevist om p...... blant enkelte enn de selv vil innrømme uten at jeg skal utdype det :-X ..........farlig sånt

Når det er sagt så er jo selvfølgelig også jeg interessert i saker og ting som kan forbedre lyden ref:
www.hifisentralen.no/forum/index.php/topic,49131.msg914167.html#new

Koster det småpenger og ikke lager krøll på noe vis, så kan jeg satse bare for godfølelsen, koster det forholdsvis mye og jeg ikke evner lett å høre forskjell så velger jeg nok å avstå, særlig dersom det er fare for krøll i tillegg (ref: link til tråden)

Mvh.KW

 

[ceroxol]

Skyt om ønskelig "EMM Labs' Shahin Al Rashid" ikke meg om vedkommende har kommet med uttalelser som ikke holder mål ;D

Sånn jeg leser beskrivelsen av "MFAST", så leser jeg bare om nok en krykkeløsning, hvor markedsavdelingen har funnet en fint navn.. The method is entirely digital.... Jøss..

Det kan selvfølgelig hende jeg tar grundig feil her, men "MFAST" virker unødvendig komplisert i forhold til å bare benytte den asynkrone overføringen med en gang.. Da har jo dac/klokke kontroll på innkommende data, uten at det trengs masse etterbehandling for å fjerne jitter/gi et jitterfritt signal til d/a.

Litt på siden kanskje, men likevel. Tidligere oppgraderte en jo gjerne CDP med en ekstra innstallert klokke (LClock var vel i vinden?). Slike kan vel installeres i eksterne DACer også vil jeg tro (- eller er jeg på bærtur her?)

Hypotetisk tenkt: Gitt at asynkrone DACer er SOTA, hvilken fordeler har disse i forhold til DACer med f.eks. en LClock? Oppnår en ikke «det samme»?

Nei, det tror jeg ikke (sier tror )
Det er vel bare kvalitetsforskjeller (nøyaktighet) på klokker det er snakk om, spørs om ikke det (også?) er snakk om markedsføring alternativt mikromessige måleforskjeller mer enn reelt hørbart (for slike som oss : )

Enig, her er det snakk om kvalitet/nøyaktighet/stabilitet/etc. på klokken, ikke noe annet.

 

[KW]

Skyt om ønskelig "EMM Labs' Shahin Al Rashid" ikke meg om vedkommende har kommet med uttalelser som ikke holder mål ;D

Sånn jeg leser beskrivelsen av "MFAST", så leser jeg bare om nok en krykkeløsning, hvor markedsavdelingen har funnet en fint navn.. The method is entirely digital.... Jøss..

Litt på siden kanskje, men likevel. Tidligere oppgraderte en jo gjerne CDP med en ekstra innstallert klokke (LClock var vel i vinden?). Slike kan vel installeres i eksterne DACer også vil jeg tro (- eller er jeg på bærtur her?)

Hypotetisk tenkt: Gitt at asynkrone DACer er SOTA, hvilken fordeler har disse i forhold til DACer med f.eks. en LClock? Oppnår en ikke «det samme»?

Nei, det tror jeg ikke (sier tror )
Det er vel bare kvalitetsforskjeller (nøyaktighet) på klokker det er snakk om, spørs om ikke det (også?) er snakk om markedsføring alternativt mikromessige måleforskjeller mer enn reelt hørbart (for slike som oss : )

Enig, her er det snakk om kvalitet/nøyaktighet/stabilitet/etc. på klokken, ikke noe annet.

Til det første, det som sies er vel å få ned mest mulig jitterverdiene, har du noe å komme med at MFAST ikke greier det om enn på en annen måte enn asynkrone USB dacer med tilsvarende resultat, så ville nok det vært et greiere svar enn det du har kommet med, ikke minst på det grunnlaget hvor asynkron og hevdet lavere jitter også av enkelte hevdes å være noe lignende (markedsføring uten reell verdi rent lyttemessig for folk flest)

Mvh.KW

 

[KW]

ceroxol skre;Det kan selvfølgelig hende jeg tar grundig feil her, men "MFAST" virker unødvendig komplisert i forhold til å bare benytte den asynkrone overføringen med en gang.. Da har jo dac/klokke kontroll på innkommende data, uten at det trengs masse etterbehandling for å fjerne jitter/gi et jitterfritt signal til d/a.

Fordelen med MFAST(med mulighet for at også jeg tar feil ) er jo at denne virker på alle de digitale inngangene og uansett hvor de (signalene) kommer fra, så langt jeg skjønner

asynkron er vel kun mulig i forbindelse med usb overføring av digitalisen, alternativt med egen klokkeinngang på dac, og det er nettopp dette som EmmLabs hevder unødvendiggjør egen klokkeinngang.

Edit; Til det siste du skrev oppe her, så langt jeg har skjønt så er det ikke snakk om noen etterbehandling det gjøres on the fly i kretsens elastiske buffer (ikke spør meg om hva det er) men uansett så vil det jo dermed ha samme virkning på alle de digitale inngangene og ikke bare USB
Mvh.KW

 

[Brianh]

Litt på siden kanskje, men likevel. Tidligere oppgraderte en jo gjerne CDP med en ekstra innstallert klokke (LClock var vel i vinden?). Slike kan vel installeres i eksterne DACer også vil jeg tro (- eller er jeg på bærtur her?)

Hypotetisk tenkt: Gitt at asynkrone DACer er SOTA, hvilken fordeler har disse i forhold til DACer med f.eks. en LClock? Oppnår en ikke «det samme»?

Med en LC clock utnyttet 100% så får du full synkronisering mellom driv og dac. LC Klokka som har 2 utganger monteres i dacen. receiver chipen bypasses og en 1 utgang brukes i dac og den andre utgangen føres tilbake via coax til driverket. Original Klokka i drivverket fjernes. Det er et "men" her og det er at drivverk og dac MÅ ha samme frekvens da det nå er bare LC klokka som driver begge. Tent labs har en løsning hvor du kan synkronisere dac og driv uten samme frekvens. Fungerer også utmerket. Jitter blir redusert til et minimum og det er GODT HØRBART.

 

[_RoDa_]

Det er selvsagt fint å ha verdiene så lave som mulig. Jeg påpeker kun at de første som gikk over til "seriøs" avspilling mha USB-DACer var temmelig ekstatiske i lytterapportene (og er det fortsatt). Inkludert de jitterverdier som nødvendigvis følger med adaptiv USB (siden ingen ennå hadde laget asynkrone løsninger). Det var egentlig hele poenget mitt.
DACer med asynkron USB er ikke dyre, så dette har ikke noe med pris å gjøre. Får vel DAC med asynkron USB for 1500 kroner (fra HRT) nå om dagen.
Det er et buzzword, noe "alle" plutselig må ha. Men de funket altså helt fint uten også. Men det er kanskje ikke ørene som teller, men asynkron vs adaptiv?

De første som hørte ICE var helt ekstatiske, de første som hørte CD var helt ekstatiske...
Slik jeg har forstått det, så rekker det ikke at det kalles asynkron, det skal være "rett" asynkron også?
Wavelength har visstnok det rette, og det samme med dcs.
Nå jeg kommer så langt at jeg skal igang med PC-lyd selv, så vet jeg hvem jeg skal spørre i alle fall.
Det supre slik jeg hørte det er at en slik USB --> SPDIF konverter gjør at du får et godt drivverk som du kan benytte i en hvilken som helst DAC. forbedringen som kom ved å bytte ut Hegels innebygde USB-inngang med dcs sin konverter var intet mindre enn en fryd!!

De som ikke hører forskjell på adaptiv og asynkron kan jo bare leve lykkelig videre.

 

[KW]

Hold deg til Rega du RoDa 8)
Men vi bør vel skaffe oss rørforsterkeri
Ikke noe vits i med asynkron og transisto ;D

Mvh.KW

 

[nma]

Dette ble i det minste litt forståelig for meg - tror jeg.

Det jeg ikke forstår er hva som skjer når S/PDIF kommer inn i bildet. Jeg har tidligere vært av den oppfatning at «SPDIF is a synchronous protocol», og noe av det samme blir sagt av Kevin Halverson på slutten. Ved bruke av min HiFace (USB til S/PDIF) så får en altså ikke en asynkron DAC bare ved hjelp av dette.

På den andre side, så forstår jeg RoDa slik at det er nettopp det han kaller asynkron USB, og som har gitt ham troen på PC-lyd:



Enten er det noe jeg ikke forstår – siden jeg ikke helt ser hvordan dette henger sammen – eller så er RoDas utsagn - om jeg nå forstår ham rett - bare et eksempel på hva nb kaller buzzword (om det nå var det han brukte).

Asynkron USB brukes for å få et best mulig S/Pdif signal ut. Er ikke verre enn det.

Så langt er jeg med. Men fra det grensesnittet er det adaptivt inn i DACen.

Akkurat den funksjonen er det vel HiFace har, om jeg har forstått det rett. For meg er det ingen forskjell med eller uten HiFace i anlegget, men jeg er en gammel mann med god DAC.

Den bruker asynkron USB for å et best mulig S/Pdif signal. Ja, S/Pdif er en krykkeløsning, men ved å la en lokal klokke være referansen til S/Pdif transmitter så blir resultatet likevel mye bedre enn å bruke en PLL som i tilleg slaver til en jittery USB-strøm være referansen.
DAC'en som mottar S/Pdif og som *DA* "adapterer" seg til S/Pdif-strømmen vil da kunne jobbe under de beste betingelser.

 

[_RoDa_]

Men da jeg fikk høre forskjellen på adaptiv kontra asynkron USB til SPDIF, så ble jeg glad!

Hvilket utstyr var det?

Hegel-DACen.
Med sin egen USB-inngang, kontra via SPDIF med USB inn i dcs.

R

 

[ceroxol]

Slik jeg har forstått det, så rekker det ikke at det kalles asynkron, det skal være "rett" asynkron også?
Wavelength har visstnok det rette, og det samme med dcs.

Nå er det flere som lisensierer Streamlenght koden til Wavelenght, bl.a. Ayre QB-9 (dac) og Halide Design Bridge (usb -> s/pdif), dessuten kommer Wavelenght med en egen usb -> s/pdif snart, kalt Wavelink. Sistnevnte kommer til å støtte 24/192 og Ayre kan oppgraderes til å gjøre det samme, hvis man har behovet.. Ellers har også dCS lisensiert sin kode til Arcam og deres nye rDAC.

Felles for alle disse er at de er plug-and-play, hvorimot m2Tech, W4S osv. krever drivere.

 

[_RoDa_]

Slik jeg har forstått det, så rekker det ikke at det kalles asynkron, det skal være "rett" asynkron også?
Wavelength har visstnok det rette, og det samme med dcs.

Nå er det flere som lisensierer Streamlenght koden til Wavelenght, bl.a. Ayre QB-9 (dac) og Halide Design Bridge (usb -> s/pdif), dessuten kommer Wavelenght med en egen usb -> s/pdif snart, kalt Wavelink. Sistnevnte kommer til å støtte 24/192 og Ayre kan oppgraderes til å gjøre det samme, hvis man har behovet.. Ellers har også dCS lisensiert sin kode til Arcam og deres nye rDAC.
Felles for alle disse er at de er plug-and-play, hvorimot m2Tech, W4S osv. krever drivere.

Takk for info. Da er det den boksen jeg venter på da. 8)

 

[KW]

Slik jeg har forstått det, så rekker det ikke at det kalles asynkron, det skal være "rett" asynkron også?
Wavelength har visstnok det rette, og det samme med dcs.

Nå er det flere som lisensierer Streamlenght koden til Wavelenght, bl.a. Ayre QB-9 (dac) og Halide Design Bridge (usb -> s/pdif), dessuten kommer Wavelenght med en egen usb -> s/pdif snart, kalt Wavelink. Sistnevnte kommer til å støtte 24/192 og Ayre kan oppgraderes til å gjøre det samme, hvis man har behovet.. Ellers har også dCS lisensiert sin kode til Arcam og deres nye rDAC.

Felles for alle disse er at de er plug-and-play, hvorimot m2Tech, W4S osv. krever drivere.

Slik jeg da forstår det, så finnes det forskjellige måter/alternativer (koder) å fremskaffe i praksis såkalt asynkron USB på, noe som vel medfører riktighet i sitert påstand i mitt tidligere innlegg i tråden ;
There are several types of asynchronous data communications techniques and what we do in the so-called 'MFAST' receiver is a specific high-speed method.

Akkurat den uttalelsen var det som fikk meg til å be dere om å skyte den som hevder det og ikke meg :
dCs har sin og Wavelength har sin og de er forskjellige (kodene) uten at jeg skjønner noe av slikt

Hele vitsen og diskusjonen går vel ut på at jitter dermed skal minskes/elimineres (om nå det siste lar seg gjøre i det hele tatt)
Om noen så får til å redusere denne type jitter (tilsvarende) på andre måter, så er det vel det som er avgjørende.

Hvilken av de to nevnte forskjellige asynkrone kodene som er best , kan jo bli den neste diskusjonen :

Hva med Weiss sin int.202 firewire interface, er den noe som på sin måte blir såkalt asynkron?

Noen som vet, for da kunne jo det være en måte for meg å få sjekket ut eventuelle forskjeller på min egen dac asynkron via denne og den "adaptive" usb inngangen jeg jo allerede har.

Ut fra Weiss int202, så blir det jo AES/EBU eller spdif, som det vel uansett på et eller annet tispunkt må innom dersom jeg har forstått det rett, om ikke noen da har denne I2S i stedet (jeg er inne på et for meg forholdsvis ukjent område nå :-\ )

Har nettopp sittet og lest Damhaug sin omtale av Weiss Dac2 (f... heter alle sammen Dac2 ;D )
og klarer ikke helt å finne ut av asynkron/adaptive for denne.

Så langt jeg sent på natta forstår, så hørte ikke han forskjell på dacen med Firewire inngangen (altså firewire fra mac til firewire på dac2) kontra samme signal fra PC -USB til dCs U-clock s/pdif derfra til Dac2

Da er vel signalet asynkront (grunnet U-clock) fra pc og dit og så gjøres det om til S-pdif fra den til Dac2.

Kan dette da skyldes at begge inngangene (eller alternativene) funker som asynkrone?

Weiss dac 2 kan også brukes som firewirekonverter, om enn et dyrere alternativ enn bare int202 konverter.

Mvh.KW

 

[helvheim]

De som har digital ut på pc/Mac kan jo med fordel brukt disse. Er mye dårlig på USB og du må nok kjøpe en dyr DAC for å få bedre lyd enn du får fra "standard " optisk/ coax til dac. Har hørt mye dårlig fra USB til dac , men samme dacen leverer mye bedre lyd dersom du bruker optisk/coax til samme dacen. Men USB er jo veldig "in" for tiden. Har du en pc/ Mac med den muligheten hadde jeg ikke vurdert USB i det hele tatt. Kjempefornøyd med den optiske fra Mac sammenlignet med USB på samme rimelige DAC

 

[ceroxol]

Hva med Weiss sin int.202 firewire interface, er den noe som på sin måte blir såkalt asynkron?

Noen som vet, for da kunne jo det være en måte for meg å få sjekket ut eventuelle forskjeller på min egen dac asynkron via denne og den "adaptive" usb inngangen jeg jo allerede har.

Ut fra Weiss int202, så blir det jo AES/EBU eller spdif, som det vel uansett på et eller annet tispunkt må innom dersom jeg har forstått det rett, om ikke noen da har denne I2S i stedet (jeg er inne på et for meg forholdsvis ukjent område nå :-\ )

Har nettopp sittet og lest Damhaug sin omtale av Weiss Dac2 (f... heter alle sammen Dac2 ;D )
og klarer ikke helt å finne ut av asynkron/adaptive for denne.

Så langt jeg sent på natta forstår, så hørte ikke han forskjell på dacen med Firewire inngangen (altså firewire fra mac til firewire på dac2) kontra samme signal fra PC -USB til dCs U-clock s/pdif derfra til Dac2

Da er vel signalet asynkront (grunnet U-clock) fra pc og dit og så gjøres det om til S-pdif fra den til Dac2.

Kan dette da skyldes at begge inngangene (eller alternativene) funker som asynkrone?

Weiss dac 2 kan også brukes som firewirekonverter, om enn et dyrere alternativ enn bare int202 konverter.

Akkurat hjemme fra nattevakt, så blir bare en kort kommentar her nå..

Ang. Weiss så er hans produkter ikke asynkrone. Det er en ganske så interessant diskusjon om emnet under testen av Weiss DAC202 på Computeraudiophile, se her (fom. inlegget til G.Rankin) - anbefalt lesning..

 

[Bjørn ("Orso")]

Det er god grunn til å ta reklamen til produsentene med en klype salt. Diskusjonen som Ceroxol henviser til er et godt eksempel på dette. Har jeg forstått det riktig så har altså Weiss hevdet at produktene deres er asynkrone, mens andre med bra kunnskap sier de ikke kan være det.

Asynkron eller ikke. Jeg har liten tro på at det er dette som er det mest avgjørende for lydkvaliteten. Vi snakker om jitter verdier som allerede er veldig lave i de fleste tilfeller og det finnes ikke noe skikkelig god bevismateriale på at enda litt lavere jitterverdien gir bedre lyd så det er sagt. Undersøkelsene er mangelfulle og det spriker litt når det gjelder hvor grensen er for hørbar sinusoidal jitter.

EMU 0404 USB er utifra det jeg leser asynkron og var muligens en av de første på markedet. Men lydkvaliteten er et godt stykke fra virkelig god. Sikkert ikke vanskelig å finne en USB DAC som er adaptiv som låter bedre. Vi vil nok se flere produsenter som skryter på seg asynkron som et salgsmiddel.

 

[vredensgnag]

Det ligger en ironi i at etterhvert som vi søker oss i retning høyoppløsning/multikanal avspilling, kan det godt være at vi når en terskel der overføringsproblemer kan melde seg - men med dagens datamengder musikk som skal overføres så er det neglisjérbart.
Og som vi har sett er lagrings- og overføringskapasitet noe som vokser eksponensielt, samtidig som pålitelighet og stabilitet også har økt.

Diskusjonen borte på CA minner om da Progressive Audio spurte ti utviklere om hva som var viktig i Computer Audio, og vi fikk 1010 svar.

På den annen side er det ingen grunn til å ikke velge oppsett med klokkestyring fra DAC og buffer for kontroll av dataintegritet. Virker som om DICE chip'en i Weiss er overimplementering i forhold til hva som er ideelt, i forhold til hva B.J. fra Metric Halo skriver senere i tråden.

Slik jeg leser tråden på Computeraudiophile kan det se ut som om Weiss bruker t.c. electronics innmat.
Men det jeg stusser på er denne stabilitetsfunksjonen som DICE chip nødvendiggjør - merkelig at de ikke bare bruker standardbehandlingen til t.c.?

This interpretation is further supported by the existence of the Operation Mode / Stability setting in the DAC202 control panel software. This appears to control the parameters of the PLL. It would not be needed if the DAC202 were using a fixed master clock instead of a PLL.

Det virker som om de har gått en omvei i forhold til å anvende det opprinnelige JET klokkesynkroniseringssystemet til t.c. -- men også viktig å få med seg distinksjonen som Weiss nevner her - de har valgt isochron overføring fordi de også ønsker å sende kontrolldata uten å forstyrre den avsatte båndbredden til musikkdata. (Slik deling er helt vanlig.)

First thanks to Chris for his favorable review. Very much appreciated.

Here is an explanation of how the Firewire (or IEEE1394 or 1394 for short) transmission works in the case of our Firewire based units.

The Firewire bus is used in the so called isochronous mode. This mode has the advantage that a fixed amount of the bus bandwidth is reserved for audio transfer. The remaining amount is available for possible control data. This means that it can not happen that there are sample losses due to bus congestion.

The devices hooked up to a Firewire bus are called Nodes. I.e. the computer is a node, the DAC202 is a node, there can be several DAC202 units on the bus for multichannel playback, each of them is a node.

Each node has by Firewire standard a fixed 24.576 MHz clock with a +- 50ppm tolerance built in. In each node that clock drives a a counter counting the 24.576 MHz clock cycles. This is the “local timer” as referred to below.
From the DICE manual:
“All nodes on a 1394 network must be synchronized to one clock called the cycle timer, which is determined by the master node on the network. One cycle of the master nodes’ cycle timer defines a 1394 cycle. At the beginning of each 1394 cycle the master node transmits a clock sync signal that allows all nodes on the 1394 network to be synchronized to the cycle timer. This maintains synchronicity among all the 1394 nodes. Each 1394 node receives the clock sync signal and uses it to update or correct its local timer.“

So in essence there is a master node which broadcasts a clock sync signal every 125 microseconds to all other nodes. This sync signal resets the “local timers” in all nodes in order to realign them to the master node. As the 24.576 MHz oscillators are obviously not synced between the nodes, there will be jitter in the local timers due to the sync signal coming from the master node. If a slave node has a D/A converter running off the Firewire bus, the associated PLL has to cope with that jitter. I.e. the PLL has to be very well designed to get decent jitter figures. The so called JET PLL used in the Dice for that purpose is described in (1).
The DAC202 is potentially a slave node if there are more than one DAC202 on the bus. If there is a single DAC202 on the bus, it is the master node and thus the source of the wordclock (sampling rate). This is the case with the wordclock generated internal to the DAC202. Alternatively with the DAC202 slaved to an external sync via its AES/EBU inputs or Wordclock input, the external sync source is the master for the Firewire transmission. The case where a AES/EBU source is connected to the DAC202 and the data transferred to the computer for recording, shows that the DAC202 obviously can control the Firewire bus and thus is not synced to a clock coming via Firewire.

The JET PLL also generates all standard sampling rates out of a single crystal oscillator when in internal sync mode. This shows that the JET PLL has the necessary quality in terms of jitter performance.

(1)http://www.tctechnologies.tc/downloads/jetpll/docs/jetpll_aes_paper.pdf
(2)http://www.tctechnologies.tc/index.php?option=com_content&view=article&id=10&Itemid=14

Etter å ha lest tråden er jeg forvirret på et ekstremt mye høyere plan.

 

[_RoDa_]

De som har digital ut på pc/Mac kan jo med fordel brukt disse. Er mye dårlig på USB og du må nok kjøpe en dyr DAC for å få bedre lyd enn du får fra "standard " optisk/ coax til dac. Har hørt mye dårlig fra USB til dac , men samme dacen leverer mye bedre lyd dersom du bruker optisk/coax til samme dacen. Men USB er jo veldig "in" for tiden. Har du en pc/ Mac med den muligheten hadde jeg ikke vurdert USB i det hele tatt. Kjempefornøyd med den optiske fra Mac sammenlignet med USB på samme rimelige DAC

Helt enig. Det er i dag blitt en nødvendighet å utstyre DACer med USBinngang, og det er ikke nødvendigvis slik at produsentene da implementerer dette på best mulig vis.

Så får man enten bruke ørene eller måledata for å finne ut hva man vil ha.

R

 

[achri-d]

Har nettopp sittet og lest Damhaug sin omtale av Weiss Dac2 (f... heter alle sammen Dac2 ;D )og klarer ikke helt å finne ut av asynkron/adaptive for denne.

Hei KW - det var uklart for meg om Weiss DAC2 sin Firewire implementasjon kunne defineres som async eller noe annet da jeg skrev omtalen.

For øvrig leste jeg nettopp en del av Weiss DAC202-tråden og ser at Wavelength beskriver async slik:

Really the only true way to accomplish an Asynchronous method for a dac is to have fixed oscillators at the dac chip and use these oscillators to derive the I2S feed going to the dac chip. Therefore the only real protocol between the Computer and the DAC would have to have some inherent feedback or flow control to make for an asynchronous link.

Og Weiss definerer async slik:

As for the async definition – in my (highend - audio) book a async DAC has a independent local clock to which the audio source is slaved. How that clock is generated is another issue and has nothing to do with the async concept. The DAC202 uses this concept of async clocking.

Mvh.

 

[nma]

Weiss går rundt grøten. De har tydeligvis lyst å henge seg på dette nye buzzwordet, men kommer bare med forklaringer som gjør folk enda mer forvirret.

For å ta det på godt norsk:
DAC202 er ikke mer async enn f.eks Becnhmark DAC-1, og protokollmessig er ingen av dem asynkrone.
Men hvis Weiss har lyst å definere async som en DAC som upsampler (som drives da av en lokal klokke, "asynkron" i forhold til resten) so be it. Da er plutselig Hegel/EC m-fl sine dac'er også async.

 

[Nordenstam]

Weiss går rundt grøten. De har tydeligvis lyst å henge seg på dette nye buzzwordet, men kommer bare med forklaringer som gjør folk enda mer forvirret.

Synkron og asynkron har vært brukt som begrep i en hel evighet. I kommunikasjonsindustrien generelt betyr begrepene hva ordene i seg selv betyr fra gresk.

Synkron: samme klokke på kilde og mottager (slik det er med USB dac'ene som beskrives som "asynkron" her).

Asynkron: ikke samme klokken på kilde og mottager(som f.eks. Benchmark DAC1).

 

[nma]

Gå tilbake og les svaret jeg ga deg tidligere.

Asynkron upsampling er ikke det samme som asynkron overføring/protokollmessig/USB.

 

[vredensgnag]

Gå tilbake og les svaret jeg ga deg tidligere.

Asynkron upsampling er ikke det samme som asynkron overføring/protokollmessig/USB.

Men kanskje bør du også lese svaret til Weiss på siste side i tråden - han nevner ikke asynkron upsampling.

Han skiller mellom isochron og asynchron overføring, og hva som er viktig der -- og hvordan generert klokkepuls implementeres. Som flere i tråden er inne på, har Rankin laget sin egen definisjon på dette, mens det er andre implementeringer som oppnår samme effekt.


Det følgende er, kort sammenfattet, Rankins påstand, som beskrevet av en annen -- og den ble tilbakevist av flere deltagere i tråden, og kanskje best av idiot_savants innlegg.
http://www.computeraudiophile.com/content/Weiss-Engineering-DAC202-Review#comment-47575



Anbefaler at man leser Weiss kommentar, ved Daniel, på siste side.
http://www.computeraudiophile.com/content/Weiss-Engineering-DAC202-Review#comment-48008

 

[nma]

Den PLL'en til som Weiss bruker adapterer seg hele tiden til USB-strømmen. Altså prøver den å synkronisere seg til den innkommende strømmen. Det er motsatt ved en asynkron DAC. Da er det flow-controll av datastrømmen.
Det er *ikke* andre implementeringer enn Gordon sin implementering som oppnår samme effekt. Det er bare ikke mulig.
At Weiss kan oppnå gode tall på papiret med en PLL og ESS9018 sin interne asynkrone upsampling, (og AD1896 i Benchmark DAC1 sitt tilfelle) er en helt annen ting og har ingenting med async eller ikke å gjøre.

 

[KW]

En ting jeg undrer på, hva da med intgrerte cdspillere, der er det jo også en datastrøm fra leserdel til DA delen og i tillegg feilkorrigeringskrets.
For at sistnevnte skal kunne fungere så må dataene kunne leses noe tid i forkant av selve formidlingen,altså ikke like direkte som f.eks. vinyl.
Hvori ligger selve forskjellen på behandlingen av dataene?
Torsten Loechs AMR (ytterligere en av diyguruene som har gått til proff produksjon) C Hansen er vel også en slik (trur eg) hevder jo at integrert spiller er best, men i så fall hvorfor, jo så langt jeg husker at avstanden fra klokka til da chipen skal/bør være så kort som mulig.

Dersom signaler enten de nå kommer fra det ene eller andre holdet, nødvendigvis(?) kommer noe i forkant, og enkeltes løsning går på en form for buffring (elastisk buffer for EMM Labs sin del) og kanskje andre løsninger for andre, da vil jeg tro at så lenge det ikke blir mangel på bits (underload) og buffringen er stor nok til å takle overload, for deretter la masterclock i den angjeldende dac få det tidsriktig, altså i form av mindre jitter(?)

Er det ikke dette som til en viss grad gjør at enkelte hevder at div. memory playere lyder så godt da?
Eller misforstår jeg dette litt.

Leste testen av weiss Dac 202, kan være fristende det til høsten, sammen med en macmini i kjelleranlegget, hvor jeg vurderer å bygge opp noe rundt rør, som et anderledes alternativ til hovedanlegget)
Den 202 har vistnok også innebygd bittransparent tester, da får jeg jo også testet om optisk og trådløst AE holder mål :
Selv om vitsen/meningen er å benytte firewire.
Vil da (eventuelt) bruke den innebygde volumstyringen, siden jeg ønsker å holde dette på et anstendig prisnivå= forholdsvis lavt.

Forsåvidt artig denne "krigen" mellom de forskjellige aktørene og deres valgte løsninger, de har jo gått for det de mener (hver seg) er en god nok/best løsning og skal i neste omgang leve av det

En av de nyeste medlemmene i OAS lager egen cdspiller(e) (ikke dac, men hel integrert spiller) fortalte meg at han hadde snakket med Ed Meitner og det var i følge han ikke helt lett (diskutere alternativer), slik forstått at det var hans valg/løsninger som var de rette, visstnok ganske så bastant (han også) ;D

Mvh.KW

 

[Nordenstam]

Asynkron upsampling er ikke det samme som asynkron overføring/protokollmessig/USB.

Greit det. Synes dog ikke det bør forventes at veletablerte begreper plutselig skal skifte mening uten at folk reagerer. Det er ikke Weiss som definerer disse ordene, de definerer seg selv om man har en viss peiling på Gresk. I tillegg har ordene en klar og definert betydning innenfor elektronikk med en historikk som strekker seg i hvert fall et par tiår bakover i tid. At en kar som Daniel Weiss som har vært i industrien i en mannsalder påpeker dette handler neppe om et ønske om å forvirre leserne. Heller tvert i mot!

Det asynkrone i denne sammenheng fremstår for meg som gammelt nytt. At USB DAC'ene opererer uavhengig av klokker innvendig i datamaskinen tar jeg som en selvfølge. Er det noe spesielt med det? Finnes det noe lydkort av noe som helst kvalitet som ikke har sin egen klokke som jobber uavhengig av de andre klokkene i datamaskinen? For meg virker dette som en hel masse baluba om noe som i praksis ikke har den helt store betydningen. Det som er interessant i denne sammenheng er ikke den asynkrone biten, men at converterklokken er master-klokken for grensesnittet til datamaskinen.

"Local master clock" hadde vært et betydelig bedre begrep for det nyeste salgsbrosjyreordet!


Selvfølgelig er det gunstig med lavere jitter. Det virker også som en åpenbar løsning å la DAC'en selv være masterklokken som bestemmer når dataen skal bli sendt fra kilden. Hvor mye har det egentig å si i praksis? I virkeligheten tviler jeg på at det utgjør forskjellen som kan skille klinten fra hveten. Å behandle klokkesignalet på en god måte er fortsatt et kunstverk om målet er ekstremt lav jitter. Om denne klokken kommer direkte fra en låst krystallklokke eller fra en variabel oscillator spiller mindre rolle enn hva som faktisk skjer med klokkesignalene innvendig i boksen. Rent teknisk er det vanskeligere å hanskes med firewire og USB grensesnitt enn en enkel SPDIF strøm. Sjansen for å få digitalsøppel som flyter over i analogseksjonen øker med kompleksiteten. Har sett noen relativt dyre firewire lydkort som åpenbart har problemer med overhøring fra firewire biten til analogseksjonen (8kHz framerate i firewire).

Tviler ikke på at en god designer kan lage en helt ordinær DAC med bedre prestanda enn en dårligere designer som bruker all verdens fancy nye teknologier.

 

[nma]

Jeg vet ærlig talt ikke hvor du vil med dette, og skjønner ikke helt hvor denne Gresken kommer inn i bildet. Det asynkrone henspeiler ikke på selve datatransmission, for dette blir jo over tid synkronisert (som du riktig påpeker).

Det asynkrone i dette er at de har en lokal masterclock som er uavhengig av PC'en sin klokke. Det er kun denne definisjonen som er viktig, det er unødvendig å drasse inn gresk og alt det andre.
Hvis vi kan enes om at en låst klokke er mye bedre enn en variabel oscillator, så vil en gitt konfigurasjon med asynkron klokke også være bedre enn en som hele tiden må slave til selve USB-strømmen.

Selv om du tar det som en selvfølge at USB-DAC'ene opererer uavhengig av masterklokken, så er det like fullt kun en håndfull merker som tilbyr dette. På et annet punkt har du også rett (selv om det er OT), og det er at det finnes andre ting som er viktigere enn jitter. Men på et eller annet punkt blir dårlig jitter-ytelse akillessenen.

Man kan løse dette til en viss grad ved å trikse med asynkron upsampling eller man kan unngå hele problemet med en en riktig implementert asynkron USB/Firewire-DAC.

 

[Ludo]

@Man: Synes du er flink til å forklare de viktige begrepene og forskjellene her...

 

[Morpheus]

Nei, her var det ikke mye jeg kunne bidra med av illuminerende kunnskap, så jeg får vel bare lese og lære! Skal ha meg en HRT Music Streamer, men usikker på om det blir standard utgaven eller +modellen. Har fått med meg at den skal være asynkron hvertfall .

Uansett var alt mye enklere i den analoge tidsalderen eller?

 

[ceroxol]

@Man: Synes du er flink til å forklare de viktige begrepene og forskjellene her...

Enig - meget bra. Ellers er det masse å lese om emnet på Computeraudiophile.com, der er bl.a. flere av konstruktørene aktive og svarer på spørsmål.

Nei, her var det ikke mye jeg kunne bidra med av illuminerende kunnskap, så jeg får vel bare lese og lære! Skal ha meg en HRT Music Streamer, men usikker på om det blir standard utgaven eller +modellen. Har fått med meg at den skal være asynkron hvertfall .

I siste Hi-Fi+ (#72) er det testet div. HRT og forskjellene mellom dem diskuteres. Les testen her.

 

[Nordenstam]

Det asynkrone i dette er at de har en lokal masterclock som er uavhengig av PC'en sin klokke. Det er kun denne definisjonen som er viktig, det er unødvendig å drasse inn gresk og alt det andre.

Ikke meningen å forvirre. Definisjonen du gir er to ulike definisjoner i ett. Den ene delen, om å jobbe uavhengig av PC'ens egen klokker, betyr at alle grensensnitt verdt sin vekt i silikon er asynkron! Det skal en del til å ikke gidde å stappe inn et par med egne krystaller på et lydkort/PC-grensesnitt. Derimot er det ikke så mange som har lokal master klokke i DAC'en, den andre delen av definisjonen din. Plasseringen til masterklokken og den medfølgende klokkingen av DACen er en annen definisjon; local/external clock.

Hvis vi kan enes om at en låst klokke er mye bedre enn en variabel oscillator, så vil en gitt konfigurasjon med asynkron klokke også være bedre enn en som hele tiden må slave til selve USB-strømmen.

Har litt vansker for å enes med det. Det finnes andre løsninger på jitterproblemet enn lokal master klokke. En superduper krets med variabel "jitter immun" oscillator slår en helt streit krets med lokal master klokke. Alt avhenger av det enkelte designet! Som eksemplifisert av Daniel Weiss' post i en av trådene som lenket, hvor han beskrev sitt valg om å bruke asynkron sample rate konvertering i den ene DAC'en sin, men ikke i den andre. (begge slaver til inkommende klokke) Kan vedde på at begge DAC'ene hans slår mye annet rart som har "bedre teknologi". Teknologien er ikke bedre enn den blir brukt til. Er ytterst lite som kan sies om en krets basert på grunnleggende kretsløsninger, chip'er osv! Det eneste som teller er hva som skjer på kontaktene på chassiet.