| Forfatter |
|
KimHRasmussen Forum Bruger

Bruger siden: 14 April 2005 Lokalitet: Fyn
Status: Offline Indlæg: 756
|
| Sendt: 07 Januar 2009 kl. 23:30 | IP-adresse registreret
|
|
|
Nu har jeg i lang tid gået og undret mig over den store debat der ofte er vedrørende digital overførsel. Her tænker jeg primært på S/P-DIF. Hvordan fungerer det i virkeligheden? Jeg hører hele tiden om "kvaliteten" af digital signaloverførsel samt f.eks. kvaliteten af lydkortets digitale udgang. Jeg er godt klar over at en bit sagtens kan blive "flippet", men har S/P-DIF ikke en anordning som f.eks. CRC-check eller i det mindste parity bit check, der sørger for at fejlen bliver minimal, eller ved CRC-check 100% negligibel? Samtidig stilles der også ofte spørgsmål ved timingen af det digitale signal, men den kloge ville jo nok vælge at lægge en input-buffer før DAC eller processor og forsyne disse med deres eget clock-signal. På den måde kan en flange på en bits impuls sagtens blive forskudt ganske lidt i tid, men dette rettes alligevel. Hvis man kan overføre data 100% korrekt vha. TCP/IP over Ethernet kan man vel også gøre det i AV-verdenen. Er der nogen der lige kan give et svar på dette?
__________________ Mit Surround: SA & Primare.
|
| Til top |
|
| |
exciter Forum Bruger

Bruger siden: 06 Oktober 2003 Lokalitet: Vestjylland
Status: Offline Indlæg: 1443
|
| Sendt: 08 Januar 2009 kl. 10:54 | IP-adresse registreret
|
|
|
Der står lidt om s/pdif her: http://www.epanorama.net/documents/audio/spdif.html
Kort sagt så er forskellen mellem at overføre data over f.eks. et netværk og data via s/pdif at s/pdif ikke har nogen fejl korrektion, og det bør heller ikke være nødvendigt da det kun er envejs kommunikation. Medmindre der lifefrem er defekter i kabler eller udstyr så mistes der ikke bits ved overførsel via s/pdif, at der så kan opstå jitter er en anden snak... det kan du finde en del tråde om på dette forum.
|
| Til top |
|
| |
phoeniks Forum Bruger

Bruger siden: 19 Maj 2007 Lokalitet: København
Status: Offline Indlæg: 440
|
| Sendt: 08 Januar 2009 kl. 11:39 | IP-adresse registreret
|
|
|
der er ikke 100% korrekt overførelse vha. tcp/ip men der er mulighed for gentransmitere pakker og tcp er ikke synkront.
forstil dig nu du skal se en film 8stk HT og en skærm der alle modtager tcp/ip over ethernet
det vil være tilfældigt hvornår lyd/billed og lyd/lyd er i synk
de tekniker man bruger i AV gør det netop muligt at holde synk. (det udelukker ikke crc og fejlkorrektion)
__________________ /Brian
musik skal ses live - film skal høres i hjemmebioen
|
| Til top |
|
| |
bhaagensen Forum Bruger

Bruger siden: 13 Juli 2007 Lokalitet: Nordjylland
Status: Offline Indlæg: 879
|
| Sendt: 08 Januar 2009 kl. 16:27 | IP-adresse registreret
|
|
|
Lidt spekulation: Måske forstås dette bedst ved at inkludere lidt mere kontekst i overvejelserne. Dengang s/pdif blev født var det formentelig af praktiske, tekniske, og økonomiske årsager umuligt at anvende noget så avanceret som tcp/ip til dette brug. Nu om dage tager vi det som en selvfølge at vores køleskab implementerer tcp/ip og koster 100 kroner; i 80'erne var det altså ikke ret mange forbruger gadgets med tcp/ip støtte.
Selvom situationen er en helt anden i dag, så er det nok stadig billigere og i det hele taget simplere at udstyre et interface med s/pdif end tcp/ip. Og hvorfor skulle man ikke det. For det store, store flertal af mennesker er s/pdif jo absolut tilstrækkelig. Og selv i den lille gruppe af audiofile er der debat omkring dette med at s/pdif ikke skulle være godt nok. For statistisk set er sandsynligheden for direkte fejl over typiske s/pdif forbindelser tæt på nul. Ligeledes er de tidforskydninger der opstår af sådan en størrelsesorden at det er svært at sige om det giver anledning til hørbare fejl (derudover påstår fx. Benchmark at de kan eliminere jitter).
Så det korte af det lange er vel at s/pdif ikke gør ret meget for at sikre "præcision" i det overførte signal (hvorfra den endeløse debat blandt audiofile fødes) og at man (mod en merpris) i dag godt kunne gjort mere. Men hvorfor skulle man det når det ligevel virker fint (og er i brug i millioner af enheder).
Hmmm, Bjørn
|
| Til top |
|
| |
KimHRasmussen Forum Bruger

Bruger siden: 14 April 2005 Lokalitet: Fyn
Status: Offline Indlæg: 756
|
| Sendt: 08 Januar 2009 kl. 17:51 | IP-adresse registreret
|
|
|
Jeg kan forstå at TCP ikke skal sammenlignes direkte med S/P-DIF, men jeg kan ikke forstå at man f.eks. ikke har implementeret f.eks. en simpel overførsel hvor enkeltbit-fejl kan korrigeres. Min primære spekulation går nemlig mod dem der køber 1000++ Kr's digitalkabler i stedet for blot at anvende et almindeligt impedanstilpasset billigt antennekabel. Den optiske overførsel giver faktisk allerbedst mening idet man får en galvnisk adskillelse af stelplan på de to apparater (at component-kabler så straks ødelægger dette ved DVD-AMP er så en anden sag).
__________________ Mit Surround: SA & Primare.
|
| Til top |
|
| |
KimHRasmussen Forum Bruger

Bruger siden: 14 April 2005 Lokalitet: Fyn
Status: Offline Indlæg: 756
|
| Sendt: 08 Januar 2009 kl. 17:56 | IP-adresse registreret
|
|
|
phoeniks skrev:
der er ikke 100% korrekt overførelse vha. tcp/ip men der er mulighed for gentransmitere pakker og tcp er ikke synkront.
forstil dig nu du skal se en film 8stk HT og en skærm der alle modtager tcp/ip over ethernet
det vil være tilfældigt hvornår lyd/billed og lyd/lyd er i synk
de tekniker man bruger i AV gør det netop muligt at holde synk. (det udelukker ikke crc og fejlkorrektion)
|
|
|
Jo da. Overførslen er i sidste ende altid 100% korrekt. Som du selv nævner er der alle mulige anordninger der søger for dette, hvor retransmission blot er én af dem. CRC-check er en anden og fejlraten er forsvindende lille. Således bør afspilningen af en film på en PC med materialet liggende på disken give nøjagtig samme oplevelse som afspilning af en film på en PC med materialet liggende på en server. At streaming, der jo typisk foregår over UDP kan give forskellige oplevelse fra situation til situation er en helt anden sag. Lyd-billede sync. er jo i øvrigt noget som en god processor skal kunne tage højde for. Derudover skal kilden også være i orden, naturligvis.
__________________ Mit Surround: SA & Primare.
|
| Til top |
|
| |
Encore Forum Bruger

Bruger siden: 09 Januar 2008 Lokalitet: København
Status: Offline Indlæg: 965
|
| Sendt: 08 Januar 2009 kl. 18:04 | IP-adresse registreret
|
|
|
KimHRasmussen skrev:
Samtidig stilles der også ofte spørgsmål ved timingen af det digitale signal, men den kloge ville
jo nok vælge at lægge en input-buffer før DAC eller processor og forsyne disse med deres eget clock-signal. På den måde
kan en flange på en bits impuls sagtens blive forskudt ganske lidt i tid, men dette rettes alligevel.
|
|
|
Jeg forstår heller ikke hvorfor dette tilsyneladende ikke er mere udbredt, og jeg har talt med en ingeniør som heller ikke
kan forklare hvorfor det skal være så stort et problem. Mine og en masses andre erfaringer er dog at det kabel der
overfører S/PDIF-signalet har overordentlig stor indflydelse. Hos mig er det S/PDIF via BNC-ud- og indgangene på mit drev
og min DAC med et NLE-kabel til ca. 1800 kr. (så vidt jeg husker) der giver det bedste resultat (så LANGT det bedste
resultat). Bedre end med et 12.000 kr. AES/EBU-kabel.
|
| Til top |
|
| |
KimHRasmussen Forum Bruger

Bruger siden: 14 April 2005 Lokalitet: Fyn
Status: Offline Indlæg: 756
|
| Sendt: 08 Januar 2009 kl. 18:04 | IP-adresse registreret
|
|
|
Fandt noget i http://www.epanorama.net/documents/audio/spdif.html der antyder at mange apparater anvender en input-buffer og egen clock-generator før DAC'en. I mine øjne ville det være så dumt så dumt ikke at gøre det, hvorfor at kabel-diskussionen vedrørende de digitale kabler er helt ovre. Et ganske almindeligt 75 Ohms kabel, eller bedre, et optisk vil være mit valg selv i et 250.000 Kr's system. Der har man vel også implementeret de gode løsninger, således at kabelvalg på den digitale side er næsten irrelevant. __________________ Mit Surround: SA & Primare.
|
| Til top |
|
| |
bhaagensen Forum Bruger

Bruger siden: 13 Juli 2007 Lokalitet: Nordjylland
Status: Offline Indlæg: 879
|
| Sendt: 08 Januar 2009 kl. 18:12 | IP-adresse registreret
|
|
|
KimHRasmussen skrev:
Jeg kan forstå at TCP ikke skal sammenlignes direkte med S/P-DIF, men jeg kan ikke forstå at man f.eks. ikke har implementeret f.eks. en simpel overførsel hvor enkeltbit-fejl kan korrigeres.
|
|
|
Mit gæt er stadig at man på grundlag af hvor sjældent sådanne fejl sker (mener at have læst at under normale betingelser kan man regne med at der kun vil forekomme en enkelt bit fejl hver 48 time v konstant overførsel) samt at man ikke har antages at det ingen praktisk betydning har, vurderet at den ekstra kompleksitet ikke ville kunne betale sig. Men som sagt. Det er kun et gæt.
|
| Til top |
|
| |
Encore Forum Bruger

Bruger siden: 09 Januar 2008 Lokalitet: København
Status: Offline Indlæg: 965
|
| Sendt: 08 Januar 2009 kl. 18:21 | IP-adresse registreret
|
|
|
KimHRasmussen skrev:
Fandt noget i
http://www.epanorama.net/documents/audio/spdif.html
der antyder at mange apparater anvender en input-buffer og egen clock-generator før DAC'en.I mine øjne ville det være så
dumt så dumt ikke at gøre det, hvorfor at kabel-diskussionen vedrørende de digitale kabler er helt ovre. Et ganske
almindeligt 75 Ohms kabel, eller bedre, et optisk vil være mit valg selv i et 250.000 Kr's system. Der har man vel også
implementeret de gode løsninger, således at kabelvalg på den digitale side er næsten irrelevant. |
|
|
Sådan burde det også være fx med Benchmarken. Men if. High Fidelitys test af NLE's kabel gør det alligevel en forskel
hvilket kabel Benchmarken fødes med. Den logiske forklaring er nok at heller ikke Benchmarkens implementering af
jitterkorrektion er 100 perfekt og immun over for jitter i det indkommende signal.
|
| Til top |
|
| |
KimHRasmussen Forum Bruger

Bruger siden: 14 April 2005 Lokalitet: Fyn
Status: Offline Indlæg: 756
|
| Sendt: 08 Januar 2009 kl. 18:34 | IP-adresse registreret
|
|
|
bhaagensen skrev:
KimHRasmussen skrev:
Jeg kan forstå at TCP ikke skal sammenlignes direkte med S/P-DIF, men jeg kan ikke forstå at man f.eks. ikke har implementeret f.eks. en simpel overførsel hvor enkeltbit-fejl kan korrigeres.
|
|
|
Mit gæt er stadig at man på grundlag af hvor sjældent sådanne fejl sker (mener at have læst at under normale betingelser kan man regne med at der kun vil forekomme en enkelt bit fejl hver 48 time v konstant overførsel) samt at man ikke har antages at det ingen praktisk betydning har, vurderet at den ekstra kompleksitet ikke ville kunne betale sig. Men som sagt. Det er kun et gæt.
|
|
|
Nu er der jo fejlkorrektion -og eller detektion i alle tre midterste lag i OSI-modellen (Medie-Link-Transport-Netværk-Applikation), der tilsammen gør fejlfri overførsel mulig. Der er naturligvis den teoretiske mulighed for fejl, men den er forsvindende lille. Så lille at vi anser den for ikke eksisterende. En fejl hver 48'ende time ville i audio-sammenhænge ikke være noget problem, men i data-sammenhæng, åh jo. __________________ Mit Surround: SA & Primare.
|
| Til top |
|
| |