Hva er det EGENTLIG som foregår med USB overføring fra PC>DAC?

[Bjørn ("Orso")]

@Oblivion
Har du målt jitter digitalt utifra Lynx lydkort? Mener og ha lest at du hadde et AES16(e?) kort.

Spørs om ikke jeg står på ignorerlisten til Oblivion. Et innlegg ut i intet med andre ord. Hehe.

Asbjørn har nå et meget godt poeng. Nå er ikke jeg for min del ikke så veldig bekymret når jitterverdiene allerede er lave. Er langt ifra sikker på enda laverer verdier gir hørbar forskjell i det helle tatt. Men hvis man skal først skal bry seg om dette, hvorfor da velge USB i utgangspunktet? Både firewire og Ethernet ser ut til å være bedre teoretiske løsninger.

 

[ArildD]

Ja ja, ble ca 100 innlegg før denne tråden også ble bitter og full av sure miner. ..

Det er mulig du har rett i det, men fordi jeg bruker "ignorer" funksjonen har jeg heldigvis ikke fått det med meg så mye av dette

I en del tråder blir det ganske mange innlegg / poster som jeg ikke ser, men du verden hvor behagelig det er å slippe å få med seg alt...
Det er endel (på min ignorerings liste) som ikke bidrar (slik jeg oppfatter det) til noe positivt på HFS, men som etter beste evne ødelegger tråder og provoserer andre medlemmer.

EDIT: Tok en opptelling av "ignorerte" innlegg i denne tråden og det er nå ca. 10%.

Kjipt.
Men.. we had a good run..
Som tidligere sagt, hyggelig at det er ressurser der ute som tar seg tid til forklaringer, utredninger og dele egne erfaringer.
Det er F ikke bare bare når man risikerer all dritten..
Definitivt en håndfull medlemmer på hfs som helt klart burde fått seg et eget rom..
(ingen referanser til denne tråd)

Mvh
Veien er målet..

 

[nb]

Ikke så rart at det velges USB da det er en industristandard som er tilgjengelig over alt. Er også verdt å minne om at USB var skiiiiitbra da de første gikk over på det, til tross for at det var lenge før noen hadde hørt om "asynkron USB" - nå er jo synkron overføring regnet som bortimot ubrukelig, men det var altså helt spuerdupert for inntil kort tid siden. Ikke dermed sagt at det ikke er fordeler med asynkron, men husk altså på at synkron USB gruset SP/DIF i børjan - til tross for høyst sannsynlig betydelig dårligere jitterytelse - som jo er populært å være opptatt av. Da kan man jo kanskje spørre seg hvor nøye dette er - selv om det er fascinerende å oppnå best mulig ytelse på generelt grunnlag.

 

[Gammeln]

Hvorfor alle disse skriveriene om jitter i forbindelse med USB?
Jeg ville ikke vurdert noe annet enn asynkron USB, da er ikke jitter noe tema.

Hvor har du fått denne absurde kunnskapen fra??

Asynkron USB er like jitterutsatt som alle andre former for digitalt overføring generelt, og USB-overføring spesielt, men KAN være bedre enn standard adaptiv overføring dersom følgende to faktorer er sanne:

- det asynkrone USB-lydkortets klokke er mer nøyaktig en det PCen klarer å klokke ut selv, og
- PCens evne til å synkronisere seg til USB-lydkortets klokke via feedback-kanalen er større enn et adaptivt USB-lydkorts evne til å synkronisere seg til en lydstrøm fra PCen

I det fleste tilfeller vil man måle lavere jitter med asynkron USB, nettopp fordi de ovennevnte viser seg å være tilfelle i mange tilfeller, men jitter må fremdeles tas høyde for i kretsene, der, som alle andre steder.

Asynkron USB er IKKE at lydkortet reklokker signalet det får inn på USB-grensesnittet før det sendes ut på lydsiden, slik man kanskje intuitivt skulle tro.

Da har vi nok veldig forskjellig oppfatning av asynkron USB. I min asynkrone USB-verden er dac klokkemaster. Jitter på utsendt data fra PC har dermed ingen konsekvens så lenge mottageren klarer å hente ut datainformasjonen.

 

[ArildD]

Hvorfor alle disse skriveriene om jitter i forbindelse med USB?
Jeg ville ikke vurdert noe annet enn asynkron USB, da er ikke jitter noe tema.

Hvor har du fått denne absurde kunnskapen fra??

Asynkron USB er like jitterutsatt som alle andre former for digitalt overføring generelt, og USB-overføring spesielt, men KAN være bedre enn standard adaptiv overføring dersom følgende to faktorer er sanne:

- det asynkrone USB-lydkortets klokke er mer nøyaktig en det PCen klarer å klokke ut selv, og
- PCens evne til å synkronisere seg til USB-lydkortets klokke via feedback-kanalen er større enn et adaptivt USB-lydkorts evne til å synkronisere seg til en lydstrøm fra PCen

I det fleste tilfeller vil man måle lavere jitter med asynkron USB, nettopp fordi de ovennevnte viser seg å være tilfelle i mange tilfeller, men jitter må fremdeles tas høyde for i kretsene, der, som alle andre steder.

Asynkron USB er IKKE at lydkortet reklokker signalet det får inn på USB-grensesnittet før det sendes ut på lydsiden, slik man kanskje intuitivt skulle tro.

Da har vi nok veldig forskjellig oppfatning av asynkron USB. I min asynkrone USB-verden er dac klokkemaster. Jitter på utsendt data fra PC har dermed ingen konsekvens så lenge mottageren klarer å hente ut datainformasjonen.

Skudd fra hofta:
Skitt inn er skitt ut var det noen som sa engang.
Man vil jo ha best mulig forhold for komponentene. Så kan man unngå at elektronikk MÅ korrigere før det blir til musikk er det definitivt det beste.

Er jo tross alt derfor vi driver på med sorte koner, vibrapods, hifi møbler, riktig hastighet på platespiller og skjermede kabler +++
Jeg er enig om at vi ER uenige

MVH
Veien er målet..

 

[Gammeln]

Man vil jo ha best mulig forhold for komponentene. Så kan man unngå at elektronikk MÅ korrigere før det blir til musikk er det definitivt det beste.

Men det er jo nettopp det som er poenget. Med DAC som klokkemaster slipper man alt styret med å gjenvinne klokkeinformasjon fra et lurvete datasignal.

 

[marsboer]

Hvorfor alle disse skriveriene om jitter i forbindelse med USB?
Jeg ville ikke vurdert noe annet enn asynkron USB, da er ikke jitter noe tema.

Hvor har du fått denne absurde kunnskapen fra??

Asynkron USB er like jitterutsatt som alle andre former for digitalt overføring generelt, og USB-overføring spesielt, men KAN være bedre enn standard adaptiv overføring dersom følgende to faktorer er sanne:

- det asynkrone USB-lydkortets klokke er mer nøyaktig en det PCen klarer å klokke ut selv, og
- PCens evne til å synkronisere seg til USB-lydkortets klokke via feedback-kanalen er større enn et adaptivt USB-lydkorts evne til å synkronisere seg til en lydstrøm fra PCen

I det fleste tilfeller vil man måle lavere jitter med asynkron USB, nettopp fordi de ovennevnte viser seg å være tilfelle i mange tilfeller, men jitter må fremdeles tas høyde for i kretsene, der, som alle andre steder.

Asynkron USB er IKKE at lydkortet reklokker signalet det får inn på USB-grensesnittet før det sendes ut på lydsiden, slik man kanskje intuitivt skulle tro.

Da har vi nok veldig forskjellig oppfatning av asynkron USB. I min asynkrone USB-verden er dac klokkemaster. Jitter på utsendt data fra PC har dermed ingen konsekvens så lenge mottageren klarer å hente ut datainformasjonen.

DACen er klokkemaster ja, men du har misforstått den øvrige virkemåten.

 

[tce-teams]

Jeg bruker ein monster ultra high speed usb kabel fra pc lydkortet mitt og inn i dacen og det funker meget bra

 

[Gammeln]

Hvorfor alle disse skriveriene om jitter i forbindelse med USB?
Jeg ville ikke vurdert noe annet enn asynkron USB, da er ikke jitter noe tema.

Hvor har du fått denne absurde kunnskapen fra??

Asynkron USB er like jitterutsatt som alle andre former for digitalt overføring generelt, og USB-overføring spesielt, men KAN være bedre enn standard adaptiv overføring dersom følgende to faktorer er sanne:

- det asynkrone USB-lydkortets klokke er mer nøyaktig en det PCen klarer å klokke ut selv, og
- PCens evne til å synkronisere seg til USB-lydkortets klokke via feedback-kanalen er større enn et adaptivt USB-lydkorts evne til å synkronisere seg til en lydstrøm fra PCen

I det fleste tilfeller vil man måle lavere jitter med asynkron USB, nettopp fordi de ovennevnte viser seg å være tilfelle i mange tilfeller, men jitter må fremdeles tas høyde for i kretsene, der, som alle andre steder.

Asynkron USB er IKKE at lydkortet reklokker signalet det får inn på USB-grensesnittet før det sendes ut på lydsiden, slik man kanskje intuitivt skulle tro.

Da har vi nok veldig forskjellig oppfatning av asynkron USB. I min asynkrone USB-verden er dac klokkemaster. Jitter på utsendt data fra PC har dermed ingen konsekvens så lenge mottageren klarer å hente ut datainformasjonen.

DACen er klokkemaster ja, men du har misforstått den øvrige virkemåten.

Da tror jeg du må fortelle meg hvordan det egentlig virker

 

[marsboer]

OK, jeg skal prøve etter beste evne og mest mulig forenklet:

Adaptiv:
1. PCen sender ut en lydstrøm basert på samplingsraten og med egen klokke.
2. USB-lydkortet mottar lydstrømmen og tilpasser egen klokke etter lydstrømmen. Om innsignalet har en klokkerate på 44 050 Hz i stedet for nøyaktig 44.1kHz så kan ikke lydkortet gjøre noe med det
3. PCen korrigerer lydstrømmen ut etterhvert lydstrømmen avviker fra egen klokke

Asynkron:
1. USB-lydkortet genererer en noenlunde nøyaktig klokke, selv om denne også vil ha noe jitter som alle andre klokker
2. USB-lydkortet setter blant annet opp en enveiskanal via USB mot PCen. På denne kanalen sender lydkortet klokkefeedback.
3. PCen tar klokkefeedbacken og regner ut hvor mye utstrømmen fra PCen på samme USB-grensesnitt må korrigeres for å tilnærme seg USB-lydkortklokken etter beste evne
4. Dette gjentas igjen og igjen

Som du ser vil asynkron USB kun være et remedie mot PCens antatte klokkejitter. Feedback er, som du helt sikkert skjønner, noe som nødvendigvis må kommer i etterkant av at data er overført. Det vil derfor være et lite tidsintervall mellom det tidspunktet USB-lydkortet merker at klokken på innstrømmen avviker fra egen klokke, til PCen har fått feedback-signal på dette og har klart å korrigere feilen. Dette pågår kontinuerlig. I tillegg vil fremdeles jitter i selve den elektriske overføringen være et like stort tema som vanlig fra PCen til USB-lydkortet.


Den vanlige misforståtte og uriktige virkemåten til asynkron USB:
1. PCen sender ut en lydstrøm til USB-lydkortet
2. USB-lydkortet tar inn strømmen, bufrer den og reklokker med sin egen klokke

Basert på denne virkemåten oppstår naturlig misforståelsen om at overføringen ikke teller så lenge dataene er riktige, siden dataene uansett klokkes ut på nytt. Men dersom man faktisk tenker etter så finner man imidlertid fort ut at dette ikke hadde fungert i praksis. Når man slaver PCen til klokken til USB-lydkortet så må PCen på ett eller annet vis motta enten et klokkesignal eller et korreksjonssignal (feedback) og da ryker allerede prinsippet om uavhengig reklokking direkte i lydkortet uten at kretsen mot PCen og selve PCen blir en faktor.

Hvis man dropper dette og lar PCen styre sin egen klokke i stedet, mens data bare dyttes vilkårlig til bufferet før lydkortet gjør sin greie med egen klokke så får man et problem med å avgjøre hvor stort bufferet må være. Hva om PCen går konsekvent 100hz feil klokkemessig på sampleraten. Bufferet vil ikke kunne klare å håndtere dette over tid. Man er derfor avhengig av at PCen på ett eller annet vis mottar klokkefeedback fra lydkortet og i prinsippet havner man da på den faktiske virkemåten til asynkron USB.

Håper dette var sånn noenlunde forståelig

 

[Gammeln]

OK, jeg skal prøve etter beste evne og mest mulig forenklet:

Adaptiv:
1. PCen sender ut en lydstrøm basert på samplingsraten og med egen klokke.
2. USB-lydkortet mottar lydstrømmen og tilpasser egen klokke etter lydstrømmen. Om innsignalet har en klokkerate på 44 050 Hz i stedet for nøyaktig 44.1kHz så kan ikke lydkortet gjøre noe med det
3. PCen korrigerer lydstrømmen ut etterhvert lydstrømmen avviker fra egen klokke

Asynkron:
1. USB-lydkortet genererer en noenlunde nøyaktig klokke, selv om denne også vil ha noe jitter som alle andre klokker
2. USB-lydkortet setter blant annet opp en enveiskanal via USB mot PCen. På denne kanalen sender lydkortet klokkefeedback.
3. PCen tar klokkefeedbacken og regner ut hvor mye utstrømmen fra PCen på samme USB-grensesnitt må korrigeres for å tilnærme seg USB-lydkortklokken etter beste evne
4. Dette gjentas igjen og igjen

Som du ser vil asynkron USB kun være et remedie mot PCens antatte klokkejitter. Feedback er, som du helt sikkert skjønner, noe som nødvendigvis må kommer i etterkant av at data er overført. Det vil derfor være et lite tidsintervall mellom det tidspunktet USB-lydkortet merker at klokken på innstrømmen avviker fra egen klokke, til PCen har fått feedback-signal på dette og har klart å korrigere feilen. Dette pågår kontinuerlig. I tillegg vil fremdeles jitter i selve den elektriske overføringen være et like stort tema som vanlig fra PCen til USB-lydkortet.


Den vanlige misforståtte og uriktige virkemåten til asynkron USB:
1. PCen sender ut en lydstrøm til USB-lydkortet
2. USB-lydkortet tar inn strømmen, bufrer den og reklokker med sin egen klokke

Basert på denne virkemåten oppstår naturlig misforståelsen om at overføringen ikke teller så lenge dataene er riktige, siden dataene uansett klokkes ut på nytt. Men dersom man faktisk tenker etter så finner man imidlertid fort ut at dette ikke hadde fungert i praksis. Når man slaver PCen til klokken til USB-lydkortet så må PCen på ett eller annet vis motta enten et klokkesignal eller et korreksjonssignal (feedback) og da ryker allerede prinsippet om uavhengig reklokking direkte i lydkortet uten at kretsen mot PCen og selve PCen blir en faktor.

Hvis man dropper dette og lar PCen styre sin egen klokke i stedet, mens data bare dyttes vilkårlig til bufferet før lydkortet gjør sin greie med egen klokke så får man et problem med å avgjøre hvor stort bufferet må være. Hva om PCen går konsekvent 100hz feil klokkemessig på sampleraten. Bufferet vil ikke kunne klare å håndtere dette over tid. Man er derfor avhengig av at PCen på ett eller annet vis mottar klokkefeedback fra lydkortet og i prinsippet havner man da på den faktiske virkemåten til asynkron USB.

Håper dette var sånn noenlunde forståelig

Mesteparten stemmer med min oppfatning. Det jeg ikke får til å stemme er det du skriver om den noenlunde nøyaktige klokka i dacen (eller usb-lydkortet som du kaller det). Jeg mener dette er den høystabile klokka som styrer hele sulamitten. Slik ville i alle fall jeg konstruert det. Men jeg skal tenke gjennom sakene en gang til.

Tillegg 1:
Jeg er heller ikke enig i det du skriver om at jitter i datastrømmen har like stor betydning som ved adaptiv USB der dac-klokka genereres ut fra datastrømmen. Det er jo hele poenget ved asynkron USB.

Tillegg 2:
Jeg vet ikke om det var dCS eller Wavelength som var først ute med asynkron USB, men jeg tror ikke noen av dem ville være så dumme å ikke legge inn den vesle FIFOen som vel er forskjellen på din og min versjon. RAM er billig, det virker ikke fornuftig i det hele tatt.

 

[erato]

Hvis overføring er så problematisk: Kan vi ikke snart få en forsterker med innebygd harddisk (de er jo omtrent gratis) og med en driver til PCen som brukes som terminal for styring? Når de fleste PCer etter hvert har eksterne harddisker så kan det vel ikke være noe i veien for at forsterkeren er den eksterne harddisken?

 

[endrea]

Kan du forklare nøye hvorfor både firewire og Ethernet ser ut til å være bedre teoretiske løsninger
enn USB?

@Oblivion
Har du målt jitter digitalt utifra Lynx lydkort? Mener og ha lest at du hadde et AES16(e?) kort.

Spørs om ikke jeg står på ignorerlisten til Oblivion. Et innlegg ut i intet med andre ord. Hehe.

Asbjørn har nå et meget godt poeng. Nå er ikke jeg for min del ikke så veldig bekymret når jitterverdiene allerede er lave. Er langt ifra sikker på enda laverer verdier gir hørbar forskjell i det helle tatt. Men hvis man skal først skal bry seg om dette, hvorfor da velge USB i utgangspunktet? Både firewire og Ethernet ser ut til å være bedre teoretiske løsninger.

 

[OAlex]

OK, jeg skal prøve etter beste evne og mest mulig forenklet:

Adaptiv:
1. PCen sender ut en lydstrøm basert på samplingsraten og med egen klokke.
2. USB-lydkortet mottar lydstrømmen og tilpasser egen klokke etter lydstrømmen. Om innsignalet har en klokkerate på 44 050 Hz i stedet for nøyaktig 44.1kHz så kan ikke lydkortet gjøre noe med det
3. PCen korrigerer lydstrømmen ut etterhvert lydstrømmen avviker fra egen klokke

Asynkron:
1. USB-lydkortet genererer en noenlunde nøyaktig klokke, selv om denne også vil ha noe jitter som alle andre klokker
2. USB-lydkortet setter blant annet opp en enveiskanal via USB mot PCen. På denne kanalen sender lydkortet klokkefeedback.
3. PCen tar klokkefeedbacken og regner ut hvor mye utstrømmen fra PCen på samme USB-grensesnitt må korrigeres for å tilnærme seg USB-lydkortklokken etter beste evne
4. Dette gjentas igjen og igjen

Som du ser vil asynkron USB kun være et remedie mot PCens antatte klokkejitter. Feedback er, som du helt sikkert skjønner, noe som nødvendigvis må kommer i etterkant av at data er overført. Det vil derfor være et lite tidsintervall mellom det tidspunktet USB-lydkortet merker at klokken på innstrømmen avviker fra egen klokke, til PCen har fått feedback-signal på dette og har klart å korrigere feilen. Dette pågår kontinuerlig. I tillegg vil fremdeles jitter i selve den elektriske overføringen være et like stort tema som vanlig fra PCen til USB-lydkortet.


Den vanlige misforståtte og uriktige virkemåten til asynkron USB:
1. PCen sender ut en lydstrøm til USB-lydkortet
2. USB-lydkortet tar inn strømmen, bufrer den og reklokker med sin egen klokke

Basert på denne virkemåten oppstår naturlig misforståelsen om at overføringen ikke teller så lenge dataene er riktige, siden dataene uansett klokkes ut på nytt. Men dersom man faktisk tenker etter så finner man imidlertid fort ut at dette ikke hadde fungert i praksis. Når man slaver PCen til klokken til USB-lydkortet så må PCen på ett eller annet vis motta enten et klokkesignal eller et korreksjonssignal (feedback) og da ryker allerede prinsippet om uavhengig reklokking direkte i lydkortet uten at kretsen mot PCen og selve PCen blir en faktor.

Hvis man dropper dette og lar PCen styre sin egen klokke i stedet, mens data bare dyttes vilkårlig til bufferet før lydkortet gjør sin greie med egen klokke så får man et problem med å avgjøre hvor stort bufferet må være. Hva om PCen går konsekvent 100hz feil klokkemessig på sampleraten. Bufferet vil ikke kunne klare å håndtere dette over tid. Man er derfor avhengig av at PCen på ett eller annet vis mottar klokkefeedback fra lydkortet og i prinsippet havner man da på den faktiske virkemåten til asynkron USB.

Håper dette var sånn noenlunde forståelig

Mesteparten stemmer med min oppfatning. Det jeg ikke får til å stemme er det du skriver om den noenlunde nøyaktige klokka i dacen (eller usb-lydkortet som du kaller det). Jeg mener dette er den høystabile klokka som styrer hele sulamitten. Slik ville i alle fall jeg konstruert det. Men jeg skal tenke gjennom sakene en gang til.

Tillegg 1:
Jeg er heller ikke enig i det du skriver om at jitter i datastrømmen har like stor betydning som ved adaptiv USB der dac-klokka genereres ut fra datastrømmen. Det er jo hele poenget ved asynkron USB.

Tillegg 2:
Jeg vet ikke om det var dCS eller Wavelength som var først ute med asynkron USB, men jeg tror ikke noen av dem ville være så dumme å ikke legge inn den vesle FIFOen som vel er forskjellen på din og min versjon. RAM er billig, det virker ikke fornuftig i det hele tatt.

Enig med Gammeln her. En prosess i USB-lydkortet vil jo hele tiden kommunisere med PCen og sørge for at FIFOen inneholder nok data. Og FIFOen kan vel operere på to klokkedomener samtidig? Et for å klokke data inn fra PC, og ett som klokker data ut til DAC?

 

[marsboer]

Mesteparten stemmer med min oppfatning. Det jeg ikke får til å stemme er det du skriver om den noenlunde nøyaktige klokka i dacen (eller usb-lydkortet som du kaller det). Jeg mener dette er den høystabile klokka som styrer hele sulamitten. Slik ville i alle fall jeg konstruert det. Men jeg skal tenke gjennom sakene en gang til.

Det er akkurat slik det er konstruert. Det er jo hele poenget med asynkron USB. Det er bare slik at asynkron USB fungerer ved å styre PCen indirekte gjennom feedback, og ikke via buffer/reklokking. Ergo lever jitterproblematikken ved selve overføringen i beste velgående.

Tillegg 1:
Jeg er heller ikke enig i det du skriver om at jitter i datastrømmen har like stor betydning som ved adaptiv USB der dac-klokka genereres ut fra datastrømmen. Det er jo hele poenget ved asynkron USB.

Det er feil. Hele poenget med asynkron USB er å benytte klokken i USB-kortet som førende for utsending av datastrømmen på PCen i stedet for PCens egne klokke, fordi man vanligvis kan gjøre denne klokken mer nøyaktig. Dersom klokken i PCen er like nøyaktig som klokken i lydkortet så er det lite eller ingenting å hente vs adaptiv USB.
Begge vil være offer for jitter som oppstår i overføringen. Asynkrone USB-overføringer har imidlertid den fordelen at avvik vil bli forsøkt korrigert i neste runde ved å be PCen om å endre utsendingsraten sin, så det er derfor naturlig at avvikene blir mindre i de fleste virkelige kretser.

Tillegg 2:
Jeg vet ikke om det var dCS eller Wavelength som var først ute med asynkron USB, men jeg tror ikke noen av dem ville være så dumme å ikke legge inn den vesle FIFOen som vel er forskjellen på din og min versjon. RAM er billig, det virker ikke fornuftig i det hele tatt.

Dette er irrelevant, siden det som sagt ikke er slik asynkron USB fungerer. Det er heller ikke noen min og din versjon eller rom for tolkning her. Standarden er nøyaktig spesifisert. Jeg anbefaler at du studerer kapittel "5.12.4 Isochronous Devices" i USB 2.0 standarden om du fremdeles mener dette handler om "min og din versjon".
Det er imidlertid fullt mulig å ha en DAC-spesifikk implementasjon etter at USB har gjort sin jobb som bufrer og reklokker/upsampler og dette blir jo også gjort i noen løsninger. Dette har imidlerting ingenting med USB eller diskusjonen her å gjøre.

 

[marsboer]

Enig med Gammeln her. En prosess i USB-lydkortet vil jo hele tiden kommunisere med PCen og sørge for at FIFOen inneholder nok data. Og FIFOen kan vel operere på to klokkedomener samtidig? Et for å klokke data inn fra PC, og ett som klokker data ut til DAC?

Dere blander kortene her. Ja, det er helt klart mulig, og kanskje også fornuftig, å implementere slike løsninger og flere gjør vel også det. Men uansett kan man ikke trylle med et buffer dersom variasjonene blir for store siden det trossalt er snakk om tidskritiske data i real time.

Det er bare det at dette med bufring og reklokking ikke er en del av asynkron USB standarden. Det er helt DAC-spesifikt.
Slike løsninger ville forøvrig fungert også for adaptive løsninger. Man flytter bare korrigeringsproblematikken fra PCen til DACen.

 

[ArildD]

Hvis overføring er så problematisk: Kan vi ikke snart få en forsterker med innebygd harddisk (de er jo omtrent gratis) og med en driver til PCen som brukes som terminal for styring? Når de fleste PCer etter hvert har eksterne harddisker så kan det vel ikke være noe i veien for at forsterkeren er den eksterne harddisken?

Det kan jeg gi svar på.. Fordi når alt er i en boks. OG fungerer fantastisk heter det gjerne Linn eller Embla og koster en bunke Frogner tiere..
Har 3 sekunders linux media prosjekt på gang. Evt Win8.
Med planlagt dac innebygd fra Børresen.
lander glatt under 5k.

 

[marsboer]

Den samme problematikken gjelder selvsagt internt i boksene. Man må fremdeles ha kretskort, ledninger, protokoller for overføring av data fra A til B, gode strømforsyninger, nøyaktige klokker og tilsvarende. Fordelen er imidlertid at man har kontroll på hele miljøet og at man derfor kan minimere problemene. Men det er på ingen måte noen garanti for gode ytelser. Her, som ved alle andre løsninger, er det implementasjonen som betyr noe, ikke konseptet i seg selv.

 

[Gammeln]

Mesteparten stemmer med min oppfatning. Det jeg ikke får til å stemme er det du skriver om den noenlunde nøyaktige klokka i dacen (eller usb-lydkortet som du kaller det). Jeg mener dette er den høystabile klokka som styrer hele sulamitten. Slik ville i alle fall jeg konstruert det. Men jeg skal tenke gjennom sakene en gang til.

Det er akkurat slik det er konstruert. Det er jo hele poenget med asynkron USB. Det er bare slik at asynkron USB fungerer ved å styre PCen indirekte gjennom feedback, og ikke via buffer/reklokking. Ergo lever jitterproblematikken ved selve overføringen i beste velgående.

Tillegg 1:
Jeg er heller ikke enig i det du skriver om at jitter i datastrømmen har like stor betydning som ved adaptiv USB der dac-klokka genereres ut fra datastrømmen. Det er jo hele poenget ved asynkron USB.

Det er feil. Hele poenget med asynkron USB er å benytte klokken i USB-kortet som førende for utsending av datastrømmen på PCen i stedet for PCens egne klokke, fordi man vanligvis kan gjøre denne klokken mer nøyaktig. Dersom klokken i PCen er like nøyaktig som klokken i lydkortet så er det lite eller ingenting å hente vs adaptiv USB.
Begge vil være offer for jitter som oppstår i overføringen. Asynkrone USB-overføringer har imidlertid den fordelen at avvik vil bli forsøkt korrigert i neste runde ved å be PCen om å endre utsendingsraten sin, så det er derfor naturlig at avvikene blir mindre i de fleste virkelige kretser.

Tillegg 2:
Jeg vet ikke om det var dCS eller Wavelength som var først ute med asynkron USB, men jeg tror ikke noen av dem ville være så dumme å ikke legge inn den vesle FIFOen som vel er forskjellen på din og min versjon. RAM er billig, det virker ikke fornuftig i det hele tatt.

Dette er irrelevant, siden det som sagt ikke er slik asynkron USB fungerer. Det er heller ikke noen min og din versjon eller rom for tolkning her. Standarden er nøyaktig spesifisert. Jeg anbefaler at du studerer kapittel "5.12.4 Isochronous Devices" i USB 2.0 standarden om du fremdeles mener dette handler om "min og din versjon".
Det er imidlertid fullt mulig å ha en DAC-spesifikk implementasjon etter at USB har gjort sin jobb som bufrer og reklokker/upsampler og dette blir jo også gjort i noen løsninger. Dette har imidlerting ingenting med USB eller diskusjonen her å gjøre.

Nå syns jeg du motsier deg selv så kraftig at vi lar diskusjonen avsluttes her.

 

[marsboer]

Nå syns jeg du motsier deg selv så kraftig at vi lar diskusjonen avsluttes her.

I hodet mitt har jeg beskrevet nøyaktig den samme virkemåten i alle mine innlegg
Du må nok peke konkret på noen eksempler så jeg kan oppklare dem for deg.

 

[achri-d]

Ikke så rart at det velges USB da det er en industristandard som er tilgjengelig over alt. Er også verdt å minne om at USB var skiiiiitbra da de første gikk over på det, til tross for at det var lenge før noen hadde hørt om "asynkron USB" - nå er jo synkron overføring regnet som bortimot ubrukelig, men det var altså helt spuerdupert for inntil kort tid siden. Ikke dermed sagt at det ikke er fordeler med asynkron, men husk altså på at synkron USB gruset SP/DIF i børjan - til tross for høyst sannsynlig betydelig dårligere jitterytelse - som jo er populært å være opptatt av. Da kan man jo kanskje spørre seg hvor nøye dette er - selv om det er fascinerende å oppnå best mulig ytelse på generelt grunnlag.

Litt overrasket over ovenstående utsagn. Dette er f eks hva jeg skrev i Fidelity #46 om USB-implementasjonen i Benchmark HDR: "Det er interessant å se at Benchmark satser på en adaptiv USB-kobling når teorien dikterer at en asynkron USB-kobling er bedre. Det er imidlertid flere haker ved et slikt argument og det hele koker ned til hva som er godt nok for å redusere tidsfeilene til et nivå hvor de ikke lenger påvirker lyden hørbart. Jeg kan berolige tvilerne – denne USB-koblingen er god nok. I mitt system er det ikke mulig å tilskrive USB-koblingen noen hørbare feil, ei heller problemer sammenlignet med en Weiss Firewire kobling som jeg har hatt svært gode erfaringer med."

Det er bare det at dette med bufring og reklokking ikke er en del av asynkron USB standarden. Det er med andre ord helt DAC-spesifikt. Slike løsninger ville forøvrig fungert også for adaptive løsninger. Man flytter bare korrigeringsproblematikken fra PCen til DACen.

Det er ikke så merkelig om folk blander kortene. Det er nok uvanlig at en DAC i dag ikke har et FIFO-buffer og også reklokker datastrømmen, men det har selvsagt ingen ting med hva USB-standarden spesifiserer. Mvh

 

[OAlex]

Enig med Gammeln her. En prosess i USB-lydkortet vil jo hele tiden kommunisere med PCen og sørge for at FIFOen inneholder nok data. Og FIFOen kan vel operere på to klokkedomener samtidig? Et for å klokke data inn fra PC, og ett som klokker data ut til DAC?

Dere blander kortene her. Ja, det er helt klart mulig, og kanskje også fornuftig, å implementere slike løsninger og flere gjør vel også det. Men uansett kan man ikke trylle med et buffer dersom variasjonene blir for store siden det trossalt er snakk om tidskritiske data i real time.

Det er bare det at dette med bufring og reklokking ikke er en del av asynkron USB standarden. Det er helt DAC-spesifikt.
Slike løsninger ville forøvrig fungert også for adaptive løsninger. Man flytter bare korrigeringsproblematikken fra PCen til DACen.

Så standarden for asynkron USB standarden dekker ikke hvordan dataene klokkes inn til DAC? Det er forsåvidt fornuftig. De som implementerer løsningen står da fritt til å gjøre dataklokkingen til DAC på "riktig" eller "feil" måte.

Ved reklokking må bufferet være dimensjonert ihht responstiden fra PCen. Jeg har ikke regna på hvor stort et slikt buffer må være, men rent intuitivt vil jeg tro må det være mulig å implenentere dette uten å måtte trylle. Kanhende jeg tar feil

 

[ArildD]

Q N K T C USB-I2S Module and Analog Board
en slik tenkte jeg å bygge inn i media pc. Selvsagt skal den tortur testes mot egen dac.

 

[marsboer]

Det er ikke så merkelig om folk blander kortene. Det er nok uvanlig at en DAC i dag ikke har et FIFO-buffer og også reklokker datastrømmen, men det har selvsagt ingen ting med hva USB-standarden spesifiserer. Mvh

Det finnes helt sikkert både ett og ti FIFO-buffere i dagens DACer underveis i kretsen, men jeg kun hørt om noen DACer som gir inntrykk av å faktisk ha buffere i den hensikt å bufre mottatte data og reklokke dem. Mitt inntrykk er i hvertfall at de aller fleste prinsipielt sett kun mottar data, oversampler dem i DAC-chipen av digitaltekniske hensyn (nyquist, filtre osv) og spytter dem ut igjen på analogsiden. Noen DACer bufrer og upsampler imidlertid dataene i forkant i den hensikt å redusere jitter og det er vel først og fremst disse DACene som kanskje har en implementasjon som minner om den som er beskrevet.

 

[Bjørn ("Orso")]

Kan du forklare nøye hvorfor både firewire og Ethernet ser ut til å være bedre teoretiske løsninger
enn USB?

Nøye? Nei, da må du lese noe selv.
Det med ethernet har alledere blitt forklart av Asbjørn flere ganger. Eller kort oppsummert her:

Because of the packet-transfer protocol of Ethernet and data buffering at the end-point, the jitter of the clock in the computer is a non-issue. The only clock that is important is the one in the end-point device. [...] This would seem to be the ideal situation, which it certainly is.

Når det gjelder firewire så støtter den for det første større båndbredde og sjansen for latency er lavere. Viktig og betydningsfult til stuidobruk hvor man kjører masse kanaler. Betyr det noe til hifi? Trolig ingenting....
Men årsaken til støtte for båndbredde kan i alle fall være et teknisk argument. Det skyldes nemlig at med firewire så er overføringsprotokollen styrt av selve enheten. Mens med USB er den i utgangspunktet styrt av CPUen og belaster den mye mer. Dette unnngår kanskje en del USB løsninger?, men utgangspunktet er i alle bedre for firewire. Og trolig er det også dermed enklere å få lavere jitter verdier. Med USB virker det som man må lage ekstra omveier for å oppnå et bra resultat.

Men tviler ikke på at begge deler kan låte veldig bra og at det ikke nødvendigvis er noe hørbar forskjell når begge deler implementeres på beste måte. Og ting tyder vel på at firewire er å vei ut og thunderbolt vil overta.

 

[marsboer]

Kan du forklare nøye hvorfor både firewire og Ethernet ser ut til å være bedre teoretiske løsninger
enn USB?

Nøye? Nei, da må du lese noe selv.
Det med ethernet har alledere blitt forklart av Asbjørn flere ganger. Eller kort oppsummert her:

Because of the packet-transfer protocol of Ethernet and data buffering at the end-point, the jitter of the clock in the computer is a non-issue. The only clock that is important is the one in the end-point device. [...] This would seem to be the ideal situation, which it certainly is.

Når det gjelder firewire så støtter den for det første større båndbredde og sjansen for latency er lavere. Viktig og betydningsfult til stuidobruk hvor man kjører masse kanaler. Betyr det noe til hifi? Trolig ingenting....
Men årsaken til støtte for båndbredde kan i alle fall være et teknisk argument. Det skyldes nemlig at med firewire så er overføringsprotokollen styrt av selve enheten. Mens med USB er den i utgangspunktet styrt av CPUen og belaster den mye mer. Dette unnngår kanskje en del USB løsninger?, men utgangspunktet er i alle bedre for firewire. Og trolig er det også dermed enklere å få lavere jitter verdier. Med USB virker det som man må lage ekstra omveier for å oppnå et bra resultat.

Men tviler ikke på at begge deler kan låte veldig bra og at det ikke nødvendigvis er noe hørbar forskjell når begge deler implementeres på beste måte. Og ting tyder vel på at firewire er å vei ut og thunderbolt vil overta.

Firewire er et aktuelt alternativ, men det blir egentlig feil å dra inn ethernet her. Ethernet må sees på som en del av subsystemet utenfor den delen vi snakker om her, som faktisk er steget hvor ferdig dekodet PCM skal til DAC.
Hvis man drar inn ethernet så kan man like gjerne også dra inn S-ATA. Begge muliggjør henting av "rådata" fra filer fra en eller annen kilde før selve dekodingsløsningen.

 

[Bjørn ("Orso")]

Her er forøvrig noe Weiss skriver om firewire:

Firewire is always implemented in hardware, with a special controller chip on every device. So the load it puts on your CPU is much lighter than USB communications load, and you're much less likely to lose any sound data just because you're running fifteen things at once. Specialized hardware usually makes things faster and more reliable, and this is one of those times.
But the real reason Firewire is more reliable than USB is more fundamental than that. It's because Firewire allows two operating modes. One is asynchronous, similar to what USB uses. The other is isochronous mode, and it lets a device carve out a certain dedicated amount of bandwidth that other devices can't touch. It gets a certain number of time slices each second all its own. The advantages for audio should be obvious: that stream of data can just keep on flowing, and as long as there isn't more bandwidth demand than the wire can handle (not very likely) nothing will interfere with it. No collisions, no glitches.

Kilde: Minerva Technical Background

Weiss DAC202 var i alle fall da den ble målt i Stereophile DACen med best jitter motstand.

The jitter was too low for the Miller Analyzer to measure. Again: Wow!

Weiss DAC202 FireWire D/A converter Measurements | Stereophile.com

 

[nb]

Når det gjelder firewire så støtter den for det første større båndbredde

Det er en sannhet med visse modifikasjoner. Firewire 800 har større båndbredde enn USB 2.0 mens noen (tidligere?) FW-spekker har lavere båndbredde. USB 3.0 har mye høyere båndbredde enn FireWire.

 

[Bjørn ("Orso")]

Spørsmålet et om USB 3.0 alikevel kan gi støtte for det samme som firewire når den belaster CPUen mer. Jeg vet ikke. Har ikke sjekket i det siste hvor mange kanaler nyere USB lydkort/interface støtter. Tidligere var det i alle fall vanskelig å finne noe mer enn 8 kanaler med USB.

 

[nb]

Litt overrasket over ovenstående utsagn. Dette er f eks hva jeg skrev i Fidelity #46 om USB-implementasjonen i Benchmark HDR: "Det er interessant å se at Benchmark satser på en adaptiv USB-kobling når teorien dikterer at en asynkron USB-kobling er bedre. Det er imidlertid flere haker ved et slikt argument og det hele koker ned til hva som er godt nok for å redusere tidsfeilene til et nivå hvor de ikke lenger påvirker lyden hørbart. Jeg kan berolige tvilerne – denne USB-koblingen er god nok. I mitt system er det ikke mulig å tilskrive USB-koblingen noen hørbare feil, ei heller problemer sammenlignet med en Weiss Firewire kobling som jeg har hatt svært gode erfaringer med."

Nå er det ganske lenge siden jeg sluttet å lese Fidelity, men tror deg når du sier det

Men mitt inntrykk fra HFS er at asynkron er hot mens synkron er not. Det er imidlertid litt på siden av poenget mitt som egentlig var at synkron USB-DACer var helt fantastiske fra børjan av, og det til tross for sannsynligvis mye høyere jitter-verdier enn en kurant SP/DIF-implementasjon.

 

[marsboer]

Her er forøvrig noe Weiss skriver om firewire:

Firewire is always implemented in hardware, with a special controller chip on every device. So the load it puts on your CPU is much lighter than USB communications load, and you're much less likely to lose any sound data just because you're running fifteen things at once. Specialized hardware usually makes things faster and more reliable, and this is one of those times.
But the real reason Firewire is more reliable than USB is more fundamental than that. It's because Firewire allows two operating modes. One is asynchronous, similar to what USB uses. The other is isochronous mode, and it lets a device carve out a certain dedicated amount of bandwidth that other devices can't touch. It gets a certain number of time slices each second all its own. The advantages for audio should be obvious: that stream of data can just keep on flowing, and as long as there isn't more bandwidth demand than the wire can handle (not very likely) nothing will interfere with it. No collisions, no glitches.

Kilde: Minerva Technical Background

Weiss DAC202 var i alle fall da den ble målt i Stereophile DACen med best jitter motstand.

The jitter was too low for the Miller Analyzer to measure. Again: Wow!

Weiss DAC202 FireWire D/A converter Measurements | Stereophile.com

Anmelderen har tydeligvis lite kontroll på USB om han lirte av seg det der. Asynkron USB er en isokron operasjonsmodus med asynkron klokkesynkronisering og også her avsettes nødvendig båndbredde, av de samme årsaker. For de som vil se det svart på hvitt så er kapittel 5.6 i USB 2.0 standarden en fin innføring:

In the USB environment, requesting an isochronous transfer type provides the requester
with the following:
• Guaranteed access to USB bandwidth with bounded latency
• Guaranteed constant data rate through the pipe as long as data is provided to the pipe
• In the case of a delivery failure due to error, no retrying of the attempt to deliver the data

Uansett så er firewire et svært godt egnet medium for dette, herom hersker ingen tvil, og før asynkron USB ble "mainstream" var det et klart bedre grensesnitt. Jeg er likevel langt mer overbevist om at DACen er eksepsjonell på jitterhåndtering og målinger hovedsaklig fordi det står "Weiss" på den, og ikke primært fordi den bruker firewire som grensesnitt.

 

[marsboer]

Litt overrasket over ovenstående utsagn. Dette er f eks hva jeg skrev i Fidelity #46 om USB-implementasjonen i Benchmark HDR: "Det er interessant å se at Benchmark satser på en adaptiv USB-kobling når teorien dikterer at en asynkron USB-kobling er bedre. Det er imidlertid flere haker ved et slikt argument og det hele koker ned til hva som er godt nok for å redusere tidsfeilene til et nivå hvor de ikke lenger påvirker lyden hørbart. Jeg kan berolige tvilerne – denne USB-koblingen er god nok. I mitt system er det ikke mulig å tilskrive USB-koblingen noen hørbare feil, ei heller problemer sammenlignet med en Weiss Firewire kobling som jeg har hatt svært gode erfaringer med."

Nå er det ganske lenge siden jeg sluttet å lese Fidelity, men tror deg når du sier det

Men mitt inntrykk fra HFS er at asynkron er hot mens synkron er not. Det er imidlertid litt på siden av poenget mitt som egentlig var at synkron USB-DACer var helt fantastiske fra børjan av, og det til tross for sannsynligvis mye høyere jitter-verdier enn en kurant SP/DIF-implementasjon.

Benchmark er vel en av de som har fokusert på buffer+upsampling tilnærmingen for å eliminere jitter. Som jeg nevnte noen poster lengre opp fungerer denne tilnærmingen like bra til dette formålet for adaptive forbindelser som for asynkrone siden USB-delen ikke er relevant for produsentens implementasjon av slike teknikker i DACen.

Min egen DAC, Bryston BDA-1, er et eksempel på noen som har forsøkt på noe tilsvarende, men som ikke har hatt like stor suksess i følge jittermålingene. På denne DACen kan man imidlertid slå av funksjonaliteten om man ikke liker den (reklokking via upsampling før DAC i den hensikt å minimere jitter). Målingene tilsa ikke at DACen var dårlig på jitter, bare at jitterundertrykkingsegenskapene med upsamplingen påslått ikke var spesielt gode med et dårlig signal inn og at funksjonaliteten derfor ikke hadde noe særlig å by på i forhold til det angitte formålet.

 

[Bjørn ("Orso")]

@marsboer
Ikke utenkelig at Weiss skrev det før asynkron USB ble vanlig. Eller de velger den dårligste løsningen når de skal overbevise om at firewire er bedre....
Det med jitter og firewire er vanskelig å si. Men finnes det USB DACer med tilsvarende lav litter?

E-MU tror jeg forøvrig var en av de første med asynkron USB overføring. Jeg har fortsatt det lydkortet og bruker det til måling. Låter slettes ikke verst heller.

 

[KW]

Her er forøvrig noe Weiss skriver om firewire:

Firewire is always implemented in hardware, with a special controller chip on every device. So the load it puts on your CPU is much lighter than USB communications load, and you're much less likely to lose any sound data just because you're running fifteen things at once. Specialized hardware usually makes things faster and more reliable, and this is one of those times.
But the real reason Firewire is more reliable than USB is more fundamental than that. It's because Firewire allows two operating modes. One is asynchronous, similar to what USB uses. The other is isochronous mode, and it lets a device carve out a certain dedicated amount of bandwidth that other devices can't touch. It gets a certain number of time slices each second all its own. The advantages for audio should be obvious: that stream of data can just keep on flowing, and as long as there isn't more bandwidth demand than the wire can handle (not very likely) nothing will interfere with it. No collisions, no glitches.

Kilde: Minerva Technical Background

Weiss DAC202 var i alle fall da den ble målt i Stereophile DACen med best jitter motstand.

The jitter was too low for the Miller Analyzer to measure. Again: Wow!

Weiss DAC202 FireWire D/A converter Measurements | Stereophile.com

Passer vel å legge inn denne da fra artikkelen/testen i Sterophile.

<With our products, the FireWire connection works in the so-called isochronous mode, which means that a defined bandwidth is reserved for the link and cannot be taken by another device on the bus. To use USBspeak, the transfer is asynchronous; ie, the master clock sits in the D/A converter and the computer is slaved to it.">


Mvh.KW

 

[Asbjørn]

Det jeg har erfart med lyd er at lydkvaliteten varierer og det i seg selv er fullstendig uakseptabelt.
Over en lengre periode vil det også oppstå dropouts selv om dette er et sjeldent fenomen.
Inn med kabel og variasjonene blir borte og lydkvalteten generellt bedre.

Ja, jeg har også opplevd dropouts fra tid til annen med 24/96 over WiFi, aldri med 16/44.1. Som nevnt tidligere i tråden endte jeg også til slutt opp med kablet UTP for å slippe det. Kan ikke si jeg har merket andre forskjeller i lydkvalitet mellom kablet og WiFi enn det.

 

[marsboer]

Så vidt jeg vet benytter så godt som alle standardiserte USB 2.0-baserte multimedialøsninger (dvs med krav til fast båndbredde og latency) isokrone overføringer. Dette er ikke noe som kom med asynkron USB.

Det er derfor viktig å skille på epler og pærer her.
Selve overføringsmodusen er isokron i alle tilfeller. Dette henspeiler blant annet på dette med garantert båndbredde og latency.
En isokron overføringsmodus kan imidlertid ha ulike klokkemoduser i USB. Herunder

- asynkron (PCen sender data basert på feedback fra mottakerens klokke)
- adaptiv (PCen sender data basert på egen klokke og mottaker må gjenvinne klokke fra selve datastrømmen)
- synkron (mottaker synkroniserer klokken etter "start-of-frame" i de overførte dataene i stedet for selve datastrømmen)

Synkron klokkesynkronisering benyttes så vidt jeg vet ikke i DAC-sammenheng og dette begrepet bør derfor ikke brukes som et alias for adaptiv, siden dette faktisk er to forskjellige klokkesynkroniseringsmoduser i USB.

 

[nma]

Hvis Asbjørn opplevde meg krass tidligere, så unnskylder jeg her og nå. Litt laidback stavangersk blir lett tolka annerledes.. Men p.g.a quotingen hans opplevde jeg at han mente at mine (positive) forskjeller bunner ut i mer hørbar forvrengning. Val er som vanlig tvetydig, men jeg liker slikt, så det går helt fint.

 

[nma]

Marsboer har forøvrig helt rett i sine antakelser. Alle som er uenig eller tolker det annerledes, tar feil. Sånn er det bare. DAC202 har ikke asynkron interface/reklokking/feedback/kall-det-hva-du-vil. Den har asynkron resampling.

 

[nma]

Sikker? Stort sett den eneste som messet om USB/SPdif-adaptere i "good old days" var LMC (om jeg husker riktig da). Men det er jo en fin teori du har der da..

Litt overrasket over ovenstående utsagn. Dette er f eks hva jeg skrev i Fidelity #46 om USB-implementasjonen i Benchmark HDR: "Det er interessant å se at Benchmark satser på en adaptiv USB-kobling når teorien dikterer at en asynkron USB-kobling er bedre. Det er imidlertid flere haker ved et slikt argument og det hele koker ned til hva som er godt nok for å redusere tidsfeilene til et nivå hvor de ikke lenger påvirker lyden hørbart. Jeg kan berolige tvilerne – denne USB-koblingen er god nok. I mitt system er det ikke mulig å tilskrive USB-koblingen noen hørbare feil, ei heller problemer sammenlignet med en Weiss Firewire kobling som jeg har hatt svært gode erfaringer med."

Nå er det ganske lenge siden jeg sluttet å lese Fidelity, men tror deg når du sier det

Men mitt inntrykk fra HFS er at asynkron er hot mens synkron er not. Det er imidlertid litt på siden av poenget mitt som egentlig var at synkron USB-DACer var helt fantastiske fra børjan av, og det til tross for sannsynligvis mye høyere jitter-verdier enn en kurant SP/DIF-implementasjon.

 

[Christian D]

Det med jitter og firewire er vanskelig å si. Men finnes det USB DACer med tilsvarende lav litter?

Produsentens målinger så er usikker på om de er sammenlignbare, men Exasound sin E20 med USB har muligens tilsvarende lav jitter: exaSound Audio Design > e20 DAC > Measurements