|
Så da er det vel i orden da ?
Det er fullt mulig å lage noe som tåler mye jitter, men problemet ligget i at klokkesignalet følger den synkrone datastrømmen i S/PDIF og dens slektninger. Gitt tilstrekkelig mye tidsvariasjon i datastrømmen må også mottakeren justere klokkehastigheten for ikke å miste «lock». De mest robuste løsningene er i prinsippet en liten buffer og reklokking i DAC-boksen, men det er nesten juks.
Joda -og heldigvis får man si, ellers så hadde det ikke kommet så mye data gjennom heller. Men DC og lavfrekvenssignaler kommer ikke gjennom.
Hva mener du med denne? En pakke er 1500 MTU (bits) til en klient, det vet du vel, etter diskusjoner i forrige tråder. Jumbo frames så er det 9000, men jumbo frames er mest lagring og servere. Nettverket er ikke avhengig av tid, som nevnt veldig mange ganger før her. Det er hastigheten på nettverket som avgjør hvor mange pakker som går i sekundet. 10, 100, 1000, 10000, 25000, 40000, 100000 mbit.
Hvis vi tar utgangspunkt i 100MB/s nettverk og det faktum at hver pakke tidstagges ved mottak og settes i sammen i renderer, så var jeg bare opptatt av hvor stor del av bølgeformen som dekkes av hver pakke, gitt en samplingsfrekvens på 44.1kHz ved utklokking av bufferet. Hver bitflip inni hver pakke som mottas er jo ikke tidstagget, så jeg lurer på er om en skew mellom bits har noe å si, gitt at det brukes linær interpolasjon mellom bits (?) Etter det jeg forstår så vil ikke dette spille noen rolle så lenge sender opererer med 44.1kHz og mottaker klokker ut bufferet med den samme frekvensen. Da vil reproduksjonen av det analoge signalet etter mottak stemme overens. Vil også fase og nullgjennomgang være identisk, mao. irrelevant?
Jeg forstår ikke hva du mener med "om en skew mellom bits har noe å si, gitt at det brukes linær interpolasjon mellom bits." Det er ingen interpolasjon i dette grensesnittet. Hvis pakken ikke mottas korrekt (checksum) vil den bli forkastet og sendt på nytt. Pakkene som kommer inn til bufferen har ingen annen tidsinformasjon enn at en header for filen sier at dette er to-kanals audio med 16 bits oppløsning og 44.1 kHz samplerate. I hvilken rekkefølge pakkene kommer inn til bufferen og eksakt tidspunkt for hver pakke og hver bit har ingen ting å si, på samme måte som om du kopierer filen fra en mappe til en annen på en PC. Dette er fortsatt en asynkron overføring av en fil, ikke en synkron overføring av et audiosignal.
Det er muligens her du har misforstått noe Distinktive. I et Router/Streamer oppsett så betyr det ikke noe om det er en pakke med 44.1kHz lyd eller om det er albumcoveret eller lyrics som sendes over. De kommer sågar i tilfeldig rekkefølge og Streamer plasserer dataene der de hører hjemme.
Jeg mente linær interpolasjon etter at bits har blitt konvertert til det analoge domenet. Da vil bølgeformen være sensitiv for skew hvis ikke bits som genererer analog bølgeform kommer i rett takt.
Den interpolasjonen skjer i så fall i det øyeblikket D/A-konverteringen skjer, via upsampling etc. Det du kaller "skew" er tydligvis effekten av jitter (tidsvariasjon) i datastrømmen på dette punktet, hverken før eller etter. Dette er det eneste punktet i kjeden hvor jitter har noen betydning. Det fører fortsatt bare til at de enkelte samplepunktene forskyves med noen nanosekunder til siden for hvor de skulle ha vært, og at den rekonstruerte analoge bølgeformen for litt analog forvrengning. På analog side viser det seg som ekstra frekvenser som ikke var i det opprinnelige signalet og som heller ikke har noe harmonisk forhold til dette. Hvis det blir hørbart låter det som gammeldags "digital hardhet", "digitalitis" og hva vi nå enn kalte det da dette var en ting på sent 1980-tall. Dette er ikke en ting i moderne digitale signalkjeder.
Jeg skal finne kilden jeg brukte for dette (fra en annen tråd). Jeg er ikke så sikker på at følsomheten til en dirigent’s øre mhp. ‘tidsavvik’ lå i ms-området, slik det rapporteres.
Hvor hentes denne infoen fra (som renderer bruker)?
Det ligger i filformatet som en header. Hvis header mangler er filen korrupt og kan ikke spilles av.
Jeg hadde tidligere da «verdens mest nøyaktige klokke» i audio området.
Kom med noe som imponerer, heller enn å smiske med autoritetene her inne
Hei Asbjørn
Formatet som beskrives er standard AES3 (~S/PDIF). IC'en er en ASRC (Asynchronous Sample Rate Converter) som tar AES3 data inn og klokker det ut igjen med en annen rate. Hele poenget med teknikken som beskrives i Application Note'n er å vise hvordan chipen kunne brukes som en overgang mellom ulike implementasjoner av AES/EBU-standarden i gamle IC'er fra tidlig 1990-tall, nærmere bestemt hvis denne behøvde å sende data til en gammel Yamaha-chip. Fra linken over:
Databladet for etterfølgeren AD1893 som løste problemet internt er datert 1998, så denne teknikken for interfacing av enda eldre chips er ikke spesielt ny.
Først, hvilken hastighet er det på wifien (Mbit)?
