Klokke i drivverk/dac

Hei

Eg lurar på om klokka sit i drivverket eller dac'en når ein går for separate løysingar? Eller i begge? Litt grøn på dette feltet.

Dersom du kobler opp drivverk med vanlig spdif så er den enveis. Det betyr at :
1. Drivverk må produsere en datastrøm ut på spdif som er noenlunde klokket
2. DAC må lese strømmen fra spdif, gjenvinne klokka og enten:
2a. Stole blindt på drivverkets klokke
2b. Prøve å jevne ut gjenvunnet klokke

Dersom drivverket produserer samples med raten 44099 samples pr sekund, så er det ingen måte DAC kan "be den om å forte seg", selv om denne skulle ha verdens mest presise atom-ur innebygd. I dette tilfellet må/bør den altså bare jenke seg, og produsere samples på en litt lavere rate. Forhåpentligvis kan den gjøre det på en litt smartere måte enn å droppe/repetere samples.

Dersom høyfrekvent jitter ifbm overføring gjør at instantan klokke avviker fra "rett", så er det samtidig uønsket at det skal lede til at det aktuelle samplet forskyves i tid, siden det er en form for fase/frekvens-modulasjon ("vibrato"). I det tilfellet så er det ønskelig at en DAC har litt forsinkelse, og dermed kan spille av ett sample litt før/etter det gjenvunnet klokke tilsier.

Mao jevne ut kort-tidsavvik, men tillate lang-tids-avvik.

Jeg leter etter eksempler hvor dette faktisk har vært et problem (og ikke bare en teknisk interessant problemstilling), så jeg tar gjerne imot innspill.

-k

Da er det vel best å unngå separat dac.

Gjest skrev:

Da er det vel best å unngå separat dac.

Klikk for å utvide...

Nei, ikke nødvendigvis. En krystall på DAC-chippen som også sendes til et separat drivverk duger selvom klokken blir noe forurenset av tidsavvik. Det er den andre veien som er problemet-som nevnt her ...

knutinh skrev:

Dersom du kobler opp drivverk med vanlig spdif så er den enveis. Det betyr at :
1. Drivverk må produsere en datastrøm ut på spdif som er noenlunde klokket
2. DAC må lese strømmen fra spdif, gjenvinne klokka og enten:
2a. Stole blindt på drivverkets klokke
2b. Prøve å jevne ut gjenvunnet klokke

Klikk for å utvide...

knutinh skrev:

Jeg leter etter eksempler hvor dette faktisk har vært et problem (og ikke bare en teknisk interessant problemstilling), så jeg tar gjerne imot innspill.

Klikk for å utvide...

Jeg har Slim Devices Transporter som jeg benytter sammen med dCS Paganini DAC og Paganini klokke. Vanligvis lar jeg klokken synkronisere DAC og Transporter, evt jeg kjører DAC som "master".

Om jeg kjører enveis S/PDIF er det faktisk tidvis problemer med overføringen - ikke tidsavvik, men knepp etc (i en tidligere tråd hevdet noen at det måtte være en feil i mitt oppsett - det er det altså ikke). Dette kan demonstreres.

Mvh.

achri-d skrev:

Om jeg kjører enveis S/PDIF er det faktisk tidvis problemer med overføringen - ikke tidsavvik, men knepp etc (i en tidligere tråd hevdet noen at det måtte være en feil i mitt oppsett - det er det altså ikke). Dette kan demonstreres.

Klikk for å utvide...

1. Er det avhengig av hvilken kilde du benytter?
2. Hvilken kabel/lengde benytter du?
3. Er det med den eksterne klokken, eller intern klokke at problemet oppstår?

-k

knutinh skrev:

1. Er det avhengig av hvilken kilde du benytter?
2. Hvilken kabel/lengde benytter du?
3. Er det med den eksterne klokken, eller intern klokke at problemet oppstår?

Klikk for å utvide...

1. Bare med PC drivverk - og løsninger a la HagUsb og Transporter trådløst eller med kabel. I.e. jeg har ikke opplevd dette med standard CD-drivverk.
2. i) HagUsb: USB-kabel som følger HagUsb og 1m Stereovox XV2.
ii) Transporter: trådløst og 1m Stereovox XV2.
3. i) HagUsb kan ikke ta ekstern klokke -> enveis S/PDIF.
ii) Jeg har ikke prøvd ekstern klokke på transporter sammen med enveis S/PDIF.

Mvh.