HiFi Klubben med ny katalog

[Esp1]

Fra den nye katalogen til HiFi Klubben:

"DENON link og I-link: Disse to systemer er hver for seg løsninger på
problemet med digitaloverføring av DVD-Audio og SACD. DenonLink er Denons
alternativ, og i dag den klart beste løsningen. Via DenonLink overføres alle
digitale signaler uten noen form for konvertering. Denon har fått denne
"protokollen" godkjent fordi apparatene i begge ender skal godkjenne
hverandre (hand shaking) - noe som forhindrer ulovlig kopiering ( i skrevne
stund er DenonLink ikke endelig godkjent for SACD, men når det er gjort vil
alle Denon modeller med DenonLink kunne oppgraderes for dette) I-link
(FireWire) er en standard som blant annet Sony og Pioneer har introdusert
som konkurrent til DenonLink. I-link er basert på PCverdenens FireWire.
I-link låter imidlertid ikke så bra som DenonLink, da FireWire plages av
kraftig digitalforvrengning (kalt jitter)."



Markedsføringens forunderlige verden slår til igjen. At Denon Link skal
være noen konkurrent til i*link er vel å overdrive en smule (eller tre), og
de som har ventet over 2 år på SACD data over Denon*Link har nok et mer
pragmatisk syn på situasjonen. Og så var det det med forvregning over i*link
da...



Esp1

[John H. Edvardsen]

Post by Esp1
"DENON link og I-link: Disse to systemer er hver for seg løsninger på
problemet med digitaloverføring av DVD-Audio og SACD. DenonLink er Denons
alternativ, og i dag den klart beste løsningen. Via DenonLink overføres alle
digitale signaler uten noen form for konvertering. Denon har fått denne
"protokollen" godkjent fordi apparatene i begge ender skal godkjenne
hverandre (hand shaking) - noe som forhindrer ulovlig kopiering ( i skrevne
stund er DenonLink ikke endelig godkjent for SACD, men når det er gjort vil
alle Denon modeller med DenonLink kunne oppgraderes for dette) I-link
(FireWire) er en standard som blant annet Sony og Pioneer har introdusert
som konkurrent til DenonLink. I-link er basert på PCverdenens FireWire.
I-link låter imidlertid ikke så bra som DenonLink, da FireWire plages av
kraftig digitalforvrengning (kalt jitter)."
Markedsføringens forunderlige verden slår til igjen. At Denon Link skal
være noen konkurrent til i*link er vel å overdrive en smule (eller tre), og
de som har ventet over 2 år på SACD data over Denon*Link har nok et mer
pragmatisk syn på situasjonen. Og så var det det med forvregning over i*link
da...
Esp1

Hadde vel *kaaaaanskje* vært litt jitter hvis kabelen hadde gått til
månen.....menmen...markedsføring... <sukk>

[Thomas Bjørseth]

[...] I-link låter imidlertid ikke så bra som DenonLink, da FireWire plages av
kraftig digitalforvrengning (kalt jitter)."

Hva menes med "kraftig digitalforvrengning" i denne sammenhengen?
FireWire brukes for å overføre opp til 800 Mbit/s i dataverdenen uten at
det medfører merkbare problemer. Hvorfor skulle samme teknologi medføre
"kraftig digitalforvrengning" så fort man bruker den til å overføre
digitalisert audio (i mye lavere hastighet)?

Thomas B

[Karl Erik Sylthe]

Post by Thomas Bjørseth

[...] I-link låter imidlertid ikke så bra som DenonLink, da FireWire plages av
kraftig digitalforvrengning (kalt jitter)."

Hva menes med "kraftig digitalforvrengning" i denne sammenhengen?
FireWire brukes for å overføre opp til 800 Mbit/s i dataverdenen uten at
det medfører merkbare problemer. Hvorfor skulle samme teknologi medføre
"kraftig digitalforvrengning" så fort man bruker den til å overføre
digitalisert audio (i mye lavere hastighet)?

Vet ikke om dette automatisk er tilfelle i alle oppsett med i-link,
men i de eksemplene jeg har prøvd benyttes en toveis kommunikasjon
til å slave drivverket til klokken i DACen (receiver). Dermed blir skal
jitter fra drivverk (og forsåvidt også transmisjonsledd) bli fullstendig
eliminert, i motsetning til ordinær digital overføring.


Karl Erik Sylthe

[Anders T. Windsor]

On Mon, 30 Aug 2004 13:59:14 +0200, Karl Erik Sylthe

Post by Esp1

Post by Thomas Bjørseth

[...] I-link låter imidlertid ikke så bra som DenonLink, da FireWire

plages av

Post by Thomas Bjørseth

kraftig digitalforvrengning (kalt jitter)."

Hva menes med "kraftig digitalforvrengning" i denne sammenhengen?
FireWire brukes for å overføre opp til 800 Mbit/s i dataverdenen uten at
det medfører merkbare problemer. Hvorfor skulle samme teknologi medføre
"kraftig digitalforvrengning" så fort man bruker den til å overføre
digitalisert audio (i mye lavere hastighet)?

Vet ikke om dette automatisk er tilfelle i alle oppsett med i-link,
men i de eksemplene jeg har prøvd benyttes en toveis kommunikasjon
til å slave drivverket til klokken i DACen (receiver). Dermed blir skal
jitter fra drivverk (og forsåvidt også transmisjonsledd) bli fullstendig
eliminert, i motsetning til ordinær digital overføring.
Karl Erik Sylthe

Nå er jeg ikke med, hvorfor trengs toveis-kommunikasjon til dette? Det er
vel bare å ta imot signalene, og deretter kjøre de gjennom dacen sin
klokke før det konverteres?

AtW

[Karl Erik Sylthe]

Post by Anders T. Windsor
On Mon, 30 Aug 2004 13:59:14 +0200, Karl Erik Sylthe

Post by Esp1

Post by Thomas Bjørseth

[...] I-link låter imidlertid ikke så bra som DenonLink, da FireWire

plages av

Post by Thomas Bjørseth

kraftig digitalforvrengning (kalt jitter)."

Hva menes med "kraftig digitalforvrengning" i denne sammenhengen?
FireWire brukes for å overføre opp til 800 Mbit/s i dataverdenen uten at
det medfører merkbare problemer. Hvorfor skulle samme teknologi medføre
"kraftig digitalforvrengning" så fort man bruker den til å overføre
digitalisert audio (i mye lavere hastighet)?

Vet ikke om dette automatisk er tilfelle i alle oppsett med i-link,
men i de eksemplene jeg har prøvd benyttes en toveis kommunikasjon
til å slave drivverket til klokken i DACen (receiver). Dermed blir skal
jitter fra drivverk (og forsåvidt også transmisjonsledd) bli fullstendig
eliminert, i motsetning til ordinær digital overføring.
Karl Erik Sylthe

Nå er jeg ikke med, hvorfor trengs toveis-kommunikasjon til dette?

For å sikre mot buffer over-/underflow.

Post by Anders T. Windsor
Det er
vel bare å ta imot signalene, og deretter kjøre de gjennom dacen sin
klokke før det konverteres?

Såvidt jeg vet kreves det veldig stort buffer dersom DACen skal fullstendig
frigjøres fra klokkefrekvensen til innkommende signalstrøm.
Selvfølgelig mulig, men etter hva jeg har forstått gjøres det ikke i
praksis.
Kanskje fordi det vil gi for stor tidsforsinkelse?

Karl Erik Sylthe

[Anders T. Windsor]

On Mon, 30 Aug 2004 16:45:16 +0200, Karl Erik Sylthe

Post by Karl Erik Sylthe

Post by Anders T. Windsor
On Mon, 30 Aug 2004 13:59:14 +0200, Karl Erik Sylthe

Post by Esp1

Post by Thomas Bjørseth

[...] I-link låter imidlertid ikke så bra som DenonLink, da FireWire

plages av

Post by Thomas Bjørseth

kraftig digitalforvrengning (kalt jitter)."

Hva menes med "kraftig digitalforvrengning" i denne sammenhengen?
FireWire brukes for å overføre opp til 800 Mbit/s i dataverdenen uten

at

Post by Anders T. Windsor

Post by Esp1

Post by Thomas Bjørseth
det medfører merkbare problemer. Hvorfor skulle samme teknologi

medføre

Post by Esp1

Post by Thomas Bjørseth
"kraftig digitalforvrengning" så fort man bruker den til å overføre
digitalisert audio (i mye lavere hastighet)?

Vet ikke om dette automatisk er tilfelle i alle oppsett med i-link,
men i de eksemplene jeg har prøvd benyttes en toveis kommunikasjon
til å slave drivverket til klokken i DACen (receiver). Dermed blir

skal

Post by Esp1
jitter fra drivverk (og forsåvidt også transmisjonsledd) bli

fullstendig

Post by Esp1
eliminert, i motsetning til ordinær digital overføring.
Karl Erik Sylthe

Nå er jeg ikke med, hvorfor trengs toveis-kommunikasjon til dette?

For å sikre mot buffer over-/underflow.

Post by Anders T. Windsor
Det er
vel bare å ta imot signalene, og deretter kjøre de gjennom dacen sin
klokke før det konverteres?

Såvidt jeg vet kreves det veldig stort buffer dersom DACen skal fullstendig
frigjøres fra klokkefrekvensen til innkommende signalstrøm.
Selvfølgelig mulig, men etter hva jeg har forstått gjøres det ikke i
praksis.
Kanskje fordi det vil gi for stor tidsforsinkelse?
Karl Erik Sylthe

Ikke for å disse, men det høres lite sannsynlig ut at dett er vanskelig,
overføringsraten på audio er treg i forhold til annen digital overføring,
en buffer på feks 8 megabyte vil holde i flere sekunder, at man skulle få
buffer-underflow over ett så klippesolid overføringssystem som firewire
finner jeg personlig relativt usannsynlig. Jitter vriker forøvrig veldig
lett å ordne, jeg mistenker at årsaken er at jitter i realiteten har null
å si for lydkvaliteten, untatt i spesiellt tilfeller, men opplys meg
gjerne om du vet bedre. Kan desverre ikke så alt for mye om temaet, og det
er vasnkelig å få "seriøs" informasjon om emnet.

AtW

[Karl Erik Sylthe]

Post by Anders T. Windsor
On Mon, 30 Aug 2004 16:45:16 +0200, Karl Erik Sylthe

Post by Karl Erik Sylthe

Post by Anders T. Windsor
On Mon, 30 Aug 2004 13:59:14 +0200, Karl Erik Sylthe

Post by Esp1

Post by Thomas Bjørseth

[...] I-link låter imidlertid ikke så bra som DenonLink, da FireWire

plages av

Post by Thomas Bjørseth

kraftig digitalforvrengning (kalt jitter)."

Hva menes med "kraftig digitalforvrengning" i denne sammenhengen?
FireWire brukes for å overføre opp til 800 Mbit/s i dataverdenen uten

at

Post by Anders T. Windsor

Post by Esp1

Post by Thomas Bjørseth
det medfører merkbare problemer. Hvorfor skulle samme teknologi

medføre

Post by Esp1

Post by Thomas Bjørseth
"kraftig digitalforvrengning" så fort man bruker den til å overføre
digitalisert audio (i mye lavere hastighet)?

Vet ikke om dette automatisk er tilfelle i alle oppsett med i-link,
men i de eksemplene jeg har prøvd benyttes en toveis kommunikasjon
til å slave drivverket til klokken i DACen (receiver). Dermed blir

skal

Post by Esp1
jitter fra drivverk (og forsåvidt også transmisjonsledd) bli

fullstendig

Post by Esp1
eliminert, i motsetning til ordinær digital overføring.
Karl Erik Sylthe

Nå er jeg ikke med, hvorfor trengs toveis-kommunikasjon til dette?

For å sikre mot buffer over-/underflow.

Post by Anders T. Windsor
Det er
vel bare å ta imot signalene, og deretter kjøre de gjennom dacen sin
klokke før det konverteres?

Såvidt jeg vet kreves det veldig stort buffer dersom DACen skal fullstendig
frigjøres fra klokkefrekvensen til innkommende signalstrøm.
Selvfølgelig mulig, men etter hva jeg har forstått gjøres det ikke i
praksis.
Kanskje fordi det vil gi for stor tidsforsinkelse?
Karl Erik Sylthe

Ikke for å disse, men det høres lite sannsynlig ut at dett er vanskelig,

Jeg ser ikke at det er vanskelig, bare at det ikke blir gjort på den
måten i praksis, såvidt jeg vet.

Post by Anders T. Windsor
overføringsraten på audio er treg i forhold til annen digital overføring,
en buffer på feks 8 megabyte vil holde i flere sekunder,

...og gi "flere sekunder" tidsforsinkelse samtidig?
Jeg har en mistanke om at det er dette momentet som gjør at så godt
som alle(?) eksterne DACer i forbrukerutstyr benytter en form for synk.
til innkommende strøm. 8MB buffer er selvfølgelig ikke rocket science.

Forøvrig er ikke dette med toveis kommunikasjon _helt_ nytt i firbindelse
med digital overføring. Tag MCLarren har benyttet dette i lengre tid.

Post by Anders T. Windsor
at man skulle få
buffer-underflow over ett så klippesolid overføringssystem som firewire
finner jeg personlig relativt usannsynlig.

Nå blander du kortene, jeg snakker ikke om firewire (i-link), men om
vanlig digital overføring.

Post by Anders T. Windsor
Jitter vriker forøvrig veldig
lett å ordne,

Kan du definere "ordne"?

Post by Anders T. Windsor
jeg mistenker at årsaken er at jitter i realiteten har null
å si for lydkvaliteten, untatt i spesiellt tilfeller, men opplys meg
gjerne om du vet bedre.

I hvilken grad jitter har betydning for lydkvaliteten, har jeg
ingen personlig oppfatning om. Selv har jeg aldri satt mine bein i et
jitter,
og jeg registrerer at det er veldig ulike oppfatning omking temaet.

Det er uansett nærliggende å anta at
audioprodusentenes valg om å _ikke_ løsrive DAC-klokke
fullstendig fra klokkefrekvensen til innkommende data, er at
de anser at jitter ikke er tilstrekkelig problematisk til at de tar
ulempen med tilstrekkelig stort buffer.


Karl Erik Sylthe

[Robert Aksland]

Post by Karl Erik Sylthe

Post by Anders T. Windsor
Det er
vel bare å ta imot signalene, og deretter kjøre de gjennom dacen sin
klokke før det konverteres?

Såvidt jeg vet kreves det veldig stort buffer dersom DACen skal fullstendig
frigjøres fra klokkefrekvensen til innkommende signalstrøm.
Selvfølgelig mulig, men etter hva jeg har forstått gjøres det ikke i
praksis.
Kanskje fordi det vil gi for stor tidsforsinkelse?

Datastrømmen til en vanlig DAC holder ikke alltid samme hastighet. Det
avgjøres av klokken i utstyret som sender dataene. Dersom utstyret som
sender data har en ørliten langsommere datastrøm enn DAC, så ville en
DAC med fast klokke gått tom for data. Derfor må en SPDIF-basert DAC
regne ut en gjennomsnittshastighet for de asynkrone (!) dataene den
mottar. Hvor hørbart dette er kan diskuteres, men effekten er der.

Med toveis grensesnitt åpner det for at DAC kan ha en konstant klokke
som er synkron med D/A-kretsene. DAC kan da gi tilbakemelding på hvor
raskt den vil ha dataene, og en får synkron overføring. Igjen er det
diskutabelt om dette vil gi hørbar forbedring, men teoretisk er det i
hverfall en forbedring.

[Anders T. Windsor]

On Mon, 30 Aug 2004 17:20:58 +0200, Robert Aksland

Post by Robert Aksland

Post by Karl Erik Sylthe

Post by Anders T. Windsor
Det er
vel bare å ta imot signalene, og deretter kjøre de gjennom dacen sin
klokke før det konverteres?

Såvidt jeg vet kreves det veldig stort buffer dersom DACen skal fullstendig
frigjøres fra klokkefrekvensen til innkommende signalstrøm.
Selvfølgelig mulig, men etter hva jeg har forstått gjøres det ikke i
praksis.
Kanskje fordi det vil gi for stor tidsforsinkelse?

Datastrømmen til en vanlig DAC holder ikke alltid samme hastighet. Det
avgjøres av klokken i utstyret som sender dataene. Dersom utstyret som
sender data har en ørliten langsommere datastrøm enn DAC, så ville en
DAC med fast klokke gått tom for data. Derfor må en SPDIF-basert DAC
regne ut en gjennomsnittshastighet for de asynkrone (!) dataene den
mottar. Hvor hørbart dette er kan diskuteres, men effekten er der.

Jeg skjønner ikke helt hvorfor datastrømmen skal være tregere, det vil jo
påvirke sampling-raten i praksis, og det virker merkelig å lage en leser
som ikke klarer å lese data raskt nok til å oppfylle spsifikasjonene til
mediet.

AtW

[Sverre Brubaek]

On Mon, 30 Aug 2004 18:06:20 +0200, "Anders T. Windsor"

Post by Anders T. Windsor
On Mon, 30 Aug 2004 17:20:58 +0200, Robert Aksland

Post by Robert Aksland

Post by Karl Erik Sylthe

Post by Anders T. Windsor
Det er
vel bare å ta imot signalene, og deretter kjøre de gjennom dacen sin
klokke før det konverteres?

Såvidt jeg vet kreves det veldig stort buffer dersom DACen skal fullstendig
frigjøres fra klokkefrekvensen til innkommende signalstrøm.
Selvfølgelig mulig, men etter hva jeg har forstått gjøres det ikke i
praksis.
Kanskje fordi det vil gi for stor tidsforsinkelse?

Datastrømmen til en vanlig DAC holder ikke alltid samme hastighet. Det
avgjøres av klokken i utstyret som sender dataene. Dersom utstyret som
sender data har en ørliten langsommere datastrøm enn DAC, så ville en
DAC med fast klokke gått tom for data. Derfor må en SPDIF-basert DAC
regne ut en gjennomsnittshastighet for de asynkrone (!) dataene den
mottar. Hvor hørbart dette er kan diskuteres, men effekten er der.

Jeg skjønner ikke helt hvorfor datastrømmen skal være tregere, det vil jo
påvirke sampling-raten i praksis, og det virker merkelig å lage en leser
som ikke klarer å lese data raskt nok til å oppfylle spsifikasjonene til
mediet.
AtW

Ikke heng deg opp i om den er tregere eller raskere. Poenget er at de
ikke kan holde eksakt samme hastighet. Selv noen ppm i forskjell
mellom klokkene er nok til at du får en buffer over/underrun i
mottageren.

Dette er imidlertid ikke noe praktisk problem siden man kan redusere
jitter så mye man måtte ønske (men ikke til null) ved å bruke en PLL
med langsom regulering og litt buffer.

Med toveis kommunikasjon trenger du ikke regenerere mottagerklokken av
grensesnittet og kan bruke en lokal klokke siden du kan gi senderen
beskjed om å øke og minke farten. 'Problemet' blir dermed elliminert.

En viktigere fordel med IEEE1349 (firewire) er nok at man kan benytte
standard huber til å kople sammen utstyr og dermed ikke behøver mer
enn en port pr. apparat for å kople sammen både inn og utganger av
både lyd og bilde.

[Anders T. Windsor]

Post by Sverre Brubaek
Ikke heng deg opp i om den er tregere eller raskere. Poenget er at de
ikke kan holde eksakt samme hastighet. Selv noen ppm i forskjell
mellom klokkene er nok til at du får en buffer over/underrun i
mottageren.
Dette er imidlertid ikke noe praktisk problem siden man kan redusere
jitter så mye man måtte ønske (men ikke til null) ved å bruke en PLL
med langsom regulering og litt buffer.
Med toveis kommunikasjon trenger du ikke regenerere mottagerklokken av
grensesnittet og kan bruke en lokal klokke siden du kan gi senderen
beskjed om å øke og minke farten. 'Problemet' blir dermed elliminert.
En viktigere fordel med IEEE1349 (firewire) er nok at man kan benytte
standard huber til å kople sammen utstyr og dermed ikke behøver mer
enn en port pr. apparat for å kople sammen både inn og utganger av
både lyd og bilde.

Hvis det vrikelig er ett problem, så kan man bare øke bufferstørrelsen,
noe som er billig, spesielt tatt i betraktning hva en litt dyrere
forsterker koster, og jeg lurer fortsatt på hvordan en slik feil i
hastighet over lengre tid vil gjøre med samplingraten.

AtW

[Sverre Brubaek]

On Mon, 30 Aug 2004 19:16:08 +0200, "Anders T. Windsor"

Post by Anders T. Windsor
Hvis det vrikelig er ett problem, så kan man bare øke bufferstørrelsen,
noe som er billig, spesielt tatt i betraktning hva en litt dyrere
forsterker koster, og jeg lurer fortsatt på hvordan en slik feil i
hastighet over lengre tid vil gjøre med samplingraten.
AtW

Bufferstørrelsen er ikke så viktig, den må bare være stor nok til å ta
opp variasjonen i datarate ettersom klokkePLLen regulerer seg inn. Du
kommer nemlig ikke bort i fra at mottagerklokken må regenereres av
datastrømmen. Mer enn noen hundre byte er sannsynligvis helt
bortkastet, og som andre har påpekt er sannsynligvis forsinkelsen en
stor buffer gir en showstopper (spesielt i AV systemer).



Du kan ikke operere med en asynkron klokke ikke uten at du aksepterer
å gjenta/hoppe over noen sampler (En kur som er værre en sykdommen).
En stor buffer hjelper deg bare umiddelbart etter at datastrømmen er
opprettet. Med en gang du når over/underrun får du de samme problemene
som om du ikke hadde buffer i hele tatt.

[Anders T. Windsor]

Post by Sverre Brubaek
Du kan ikke operere med en asynkron klokke ikke uten at du aksepterer
å gjenta/hoppe over noen sampler (En kur som er værre en sykdommen).
En stor buffer hjelper deg bare umiddelbart etter at datastrømmen er
opprettet. Med en gang du når over/underrun får du de samme problemene
som om du ikke hadde buffer i hele tatt.

Ja, men å unngå under, og forsåvidt også overrun er jo veldig enkelt,
dessuten kan man enkelt unngå en forsinkelse ved å gota at avspillingen
starter før bufferen er fyllt opp, slik som på en pc, kombinert med at man
leser fortere enn man trenger (noe som er en bra strategi uansett, da det
vil forbedre mulighetene for feilkorrigering).

AtW

[Karl Erik Sylthe]

Post by Anders T. Windsor

Post by Sverre Brubaek
Du kan ikke operere med en asynkron klokke ikke uten at du aksepterer
å gjenta/hoppe over noen sampler (En kur som er værre en sykdommen).
En stor buffer hjelper deg bare umiddelbart etter at datastrømmen er
opprettet. Med en gang du når over/underrun får du de samme problemene
som om du ikke hadde buffer i hele tatt.

Ja, men å unngå under, og forsåvidt også overrun er jo veldig enkelt,
dessuten kan man enkelt unngå en forsinkelse ved å gota at avspillingen
starter før bufferen er fyllt opp, slik som på en pc, kombinert med at man
leser fortere enn man trenger (noe som er en bra strategi uansett, da det
vil forbedre mulighetene for feilkorrigering).

Det er en logisk umulighet å gardere seg mot at drivverket spiller en skive
X sekunder saktere enn DAC-klokka uten at DAC-klokka starter X sekunder
senere, hvis ikke DAC-klokka synkes til innkommende strøm.
Lesehastigheten er irrelevant.

Karl Erik Sylthe

[Karl Erik Sylthe]

Post by Karl Erik Sylthe

Post by Anders T. Windsor

Post by Sverre Brubaek
Du kan ikke operere med en asynkron klokke ikke uten at du aksepterer
å gjenta/hoppe over noen sampler (En kur som er værre en sykdommen).
En stor buffer hjelper deg bare umiddelbart etter at datastrømmen er
opprettet. Med en gang du når over/underrun får du de samme problemene
som om du ikke hadde buffer i hele tatt.

Ja, men å unngå under, og forsåvidt også overrun er jo veldig enkelt,
dessuten kan man enkelt unngå en forsinkelse ved å gota at avspillingen
starter før bufferen er fyllt opp, slik som på en pc, kombinert med at man
leser fortere enn man trenger (noe som er en bra strategi uansett, da det
vil forbedre mulighetene for feilkorrigering).

Det er en logisk umulighet å gardere seg mot at drivverket spiller en skive
X sekunder saktere enn DAC-klokka uten at DAC-klokka starter X sekunder
senere, hvis ikke DAC-klokka synkes til innkommende strøm.
Lesehastigheten er irrelevant.

Opps, litt slurvete formulert, skulle selvfølgelig være "....uten at DACen
starer avspilling X sekunder senere, o.s.v."


Karl Erik Sylthe

[Anders T. Windsor]

On Mon, 30 Aug 2004 20:02:30 +0200, Karl Erik Sylthe

Post by Karl Erik Sylthe

Post by Anders T. Windsor

Post by Sverre Brubaek
Du kan ikke operere med en asynkron klokke ikke uten at du aksepterer
å gjenta/hoppe over noen sampler (En kur som er værre en sykdommen).
En stor buffer hjelper deg bare umiddelbart etter at datastrømmen er
opprettet. Med en gang du når over/underrun får du de samme problemene
som om du ikke hadde buffer i hele tatt.

Ja, men å unngå under, og forsåvidt også overrun er jo veldig enkelt,
dessuten kan man enkelt unngå en forsinkelse ved å gota at avspillingen
starter før bufferen er fyllt opp, slik som på en pc, kombinert med at man
leser fortere enn man trenger (noe som er en bra strategi uansett, da det
vil forbedre mulighetene for feilkorrigering).

Det er en logisk umulighet å gardere seg mot at drivverket spiller en skive
X sekunder saktere enn DAC-klokka uten at DAC-klokka starter X sekunder
senere, hvis ikke DAC-klokka synkes til innkommende strøm.
Lesehastigheten er irrelevant.
Karl Erik Sylthe

Hmm? Hvorfor, la oss si man leser det 3 ganger så fort som man trenger, og
leser alt 3 ganger untatt i de feks første 3 sekundene, og har en buffer
som varer i 10 sekund, for å være på den sikre siden, bufferen er
programert slik at den refuserer informasjon den har fra før, og at den
bare fyller på en ny rekke med bits om den har ledig plass, i begynnelsen
vil jo bufferne fylles opp, så vil den holde seg noenlunde konstant.
Forsåvidt en ralativt tungvint måte å gjøre det på. Men jeg skjønner hvor
du vil, og jeg var nok for kjapp i mine antakelser i begynnelsen, så jeg
vil gjerne dreie diskusjonen vekk fra akkurat dette, da jeg synes det har
blitt en blindvei.

Til mine andre spørsmål, toveiskommunikasjon er forsåvidt en god ide,
hvorfor gjøres ikke dette over firewire istedet/i tillegg? Og hvorfor skal
jitter bli forsterket gjennom en kabel? Hvis den ikke gjør det, hva er det
som gjør dacen sin klokke bedre en spillerens?

AtW

[Karl Erik Sylthe]

Post by Anders T. Windsor
On Mon, 30 Aug 2004 20:02:30 +0200, Karl Erik Sylthe

Post by Karl Erik Sylthe

Post by Anders T. Windsor

Post by Sverre Brubaek
Du kan ikke operere med en asynkron klokke ikke uten at du aksepterer
å gjenta/hoppe over noen sampler (En kur som er værre en sykdommen).
En stor buffer hjelper deg bare umiddelbart etter at datastrømmen er
opprettet. Med en gang du når over/underrun får du de samme problemene
som om du ikke hadde buffer i hele tatt.

Ja, men å unngå under, og forsåvidt også overrun er jo veldig enkelt,
dessuten kan man enkelt unngå en forsinkelse ved å gota at avspillingen
starter før bufferen er fyllt opp, slik som på en pc, kombinert med at man
leser fortere enn man trenger (noe som er en bra strategi uansett, da det
vil forbedre mulighetene for feilkorrigering).

Det er en logisk umulighet å gardere seg mot at drivverket spiller en skive
X sekunder saktere enn DAC-klokka uten at DAC-klokka starter X sekunder
senere, hvis ikke DAC-klokka synkes til innkommende strøm.
Lesehastigheten er irrelevant.
Karl Erik Sylthe

Hmm? Hvorfor, la oss si man leser det 3 ganger så fort som man trenger, og
leser alt 3 ganger untatt i de feks første 3 sekundene, og har en buffer
som varer i 10 sekund, for å være på den sikre siden, bufferen er
programert slik at den refuserer informasjon den har fra før, og at den
bare fyller på en ny rekke med bits om den har ledig plass, i begynnelsen
vil jo bufferne fylles opp, så vil den holde seg noenlunde konstant.
Forsåvidt en ralativt tungvint måte å gjøre det på. Men jeg skjønner hvor
du vil, og jeg var nok for kjapp i mine antakelser i begynnelsen, så jeg
vil gjerne dreie diskusjonen vekk fra akkurat dette, da jeg synes det har
blitt en blindvei.
Til mine andre spørsmål, toveiskommunikasjon er forsåvidt en god ide,
hvorfor gjøres ikke dette over firewire istedet/i tillegg? Og hvorfor skal
jitter bli forsterket gjennom en kabel? Hvis den ikke gjør det, hva er det
som gjør dacen sin klokke bedre en spillerens?
AtW

[Karl Erik Sylthe]

Post by Anders T. Windsor
On Mon, 30 Aug 2004 20:02:30 +0200, Karl Erik Sylthe

Post by Karl Erik Sylthe

Post by Anders T. Windsor

Post by Sverre Brubaek
Du kan ikke operere med en asynkron klokke ikke uten at du aksepterer
å gjenta/hoppe over noen sampler (En kur som er værre en sykdommen).
En stor buffer hjelper deg bare umiddelbart etter at datastrømmen er
opprettet. Med en gang du når over/underrun får du de samme problemene
som om du ikke hadde buffer i hele tatt.

Ja, men å unngå under, og forsåvidt også overrun er jo veldig enkelt,
dessuten kan man enkelt unngå en forsinkelse ved å gota at avspillingen
starter før bufferen er fyllt opp, slik som på en pc, kombinert med at man
leser fortere enn man trenger (noe som er en bra strategi uansett, da det
vil forbedre mulighetene for feilkorrigering).

Det er en logisk umulighet å gardere seg mot at drivverket spiller en skive
X sekunder saktere enn DAC-klokka uten at DAC-klokka starter X sekunder
senere, hvis ikke DAC-klokka synkes til innkommende strøm.
Lesehastigheten er irrelevant.
Karl Erik Sylthe

Hmm? Hvorfor, la oss si man leser det 3 ganger så fort som man trenger,

DACen kan ikke lese kjappere enn den mottar informasjonen fra drivverket.

Post by Anders T. Windsor
og
leser alt 3 ganger untatt i de feks første 3 sekundene, og har en buffer
som varer i 10 sekund, for å være på den sikre siden, bufferen er
programert slik at den refuserer informasjon den har fra før, og at den
bare fyller på en ny rekke med bits om den har ledig plass, i begynnelsen
vil jo bufferne fylles opp, så vil den holde seg noenlunde konstant.

Her garderer du deg mot at drivverket spiller kjappere enn DAC-klokka,
men ikke at det spiller saktere.

Post by Anders T. Windsor
Forsåvidt en ralativt tungvint måte å gjøre det på. Men jeg skjønner hvor
du vil, og jeg var nok for kjapp i mine antakelser i begynnelsen, så jeg
vil gjerne dreie diskusjonen vekk fra akkurat dette, da jeg synes det har
blitt en blindvei.
Til mine andre spørsmål, toveiskommunikasjon er forsåvidt en god ide,
hvorfor gjøres ikke dette over firewire istedet/i tillegg?

Jeg tror du leste mitt opprinnelige innlegg litt for kjapt. Det er nettop
med i-link / firewire at det foregår 2-veis kommunikasjon.

Som sagt er jeg ikke sikker på om dette er en obligatrisk del av
i-link, eller om det er produktavhengig. Men på de systemene fra
Sony- og Pioneer jeg har prøvd med i-link, har drivverk i spiller
vært styrt fra Receiver ved bruk av i-link.

Post by Anders T. Windsor
Og hvorfor skal
jitter bli forsterket gjennom en kabel?

Dette er det andre som kan svare bedre på enn meg.
Såvidt jeg vet er det vel mer snakk om at kabel _kan_
introdusere jitter, enn at de forsterker jitter fra drivverk.
Trur eg...

Post by Anders T. Windsor
Hvis den ikke gjør det, hva er det
som gjør dacen sin klokke bedre en spillerens?

Det er slett ikke gitt at DACen har bedre klokke enn spilleren.
Men så hvis drivverket er styrt av DAC-klokka, er uansett
jitter i innkommende signal eliminert, i og med at DACen ikke
trenger å forholde seg til innkommende klokke (annet enn administrativt).


Karl Erik Sylthe

[Sverre Brubaek]

On Mon, 30 Aug 2004 20:26:42 +0200, "Anders T. Windsor"
<***@stud.ntnu.no> wrote:

[snip]

Post by Anders T. Windsor
Hmm? Hvorfor, la oss si man leser det 3 ganger så fort som man trenger, og
leser alt 3 ganger untatt i de feks første 3 sekundene, og har en buffer

Hva skal det være godt for? Da leser du netto 1 gang så fort...

Post by Anders T. Windsor
som varer i 10 sekund, for å være på den sikre siden, bufferen er
programert slik at den refuserer informasjon den har fra før, og at den

For å regne på dette må du si noe om blokkstørrelsen du bruker (i.e.
hvor mye leser du før du gjentar samme sekvens). Du kommer imidlertid
ikke noe nærere en løsning. Etter en stund vil også denne bufferen gå
i underrun/overrun.

Forøvrig vil ikke denne metoden være kompatibel med s/pdif.

Post by Anders T. Windsor
bare fyller på en ny rekke med bits om den har ledig plass, i begynnelsen
vil jo bufferne fylles opp, så vil den holde seg noenlunde konstant.
Forsåvidt en ralativt tungvint måte å gjøre det på. Men jeg skjønner hvor
du vil, og jeg var nok for kjapp i mine antakelser i begynnelsen, så jeg
vil gjerne dreie diskusjonen vekk fra akkurat dette, da jeg synes det har
blitt en blindvei.
Til mine andre spørsmål, toveiskommunikasjon er forsåvidt en god ide,
hvorfor gjøres ikke dette over firewire istedet/i tillegg? Og hvorfor skal

IEEE1349 er ikke en særlig etablert standard, koster mer enn s/pdif og
løser ingen reelle problemer for rene audioapplikasjoner.

Post by Anders T. Windsor
jitter bli forsterket gjennom en kabel? Hvis den ikke gjør det, hva er det

Teoretisk sett: Jitter øker når klokkesignalet blir
lavpassfiltrert/får tilført støy. All transmisjon av fysiske signaler
har disse effektene i noen grad, også kabelen signalet går i. Siden
klokken kommer over kabelen får det noe tilført jitter.

I praksis med jitterattenuering hos mottagere er effekten i CD-DA
systemer umerkelig.

Post by Anders T. Windsor
som gjør dacen sin klokke bedre en spillerens?

Ikke bedre, men jitter har bare en effekt på DAC. I rene
digitalkretser innfører jitter bare litt ubestemthet på klokken som
designeren vil ha tatt høyde for ved å ha litt positivt slack på alle
timingstier. (søkeord: static timing analysis, clock uncertainty)

[Karl Erik Sylthe]

Post by Sverre Brubaek
On Mon, 30 Aug 2004 20:26:42 +0200, "Anders T. Windsor"
[snip]

Post by Anders T. Windsor
Hmm? Hvorfor, la oss si man leser det 3 ganger så fort som man trenger, og
leser alt 3 ganger untatt i de feks første 3 sekundene, og har en buffer

Hva skal det være godt for? Da leser du netto 1 gang så fort...

Post by Anders T. Windsor
som varer i 10 sekund, for å være på den sikre siden, bufferen er
programert slik at den refuserer informasjon den har fra før, og at den

For å regne på dette må du si noe om blokkstørrelsen du bruker (i.e.
hvor mye leser du før du gjentar samme sekvens). Du kommer imidlertid
ikke noe nærere en løsning. Etter en stund vil også denne bufferen gå
i underrun/overrun.
Forøvrig vil ikke denne metoden være kompatibel med s/pdif.

Post by Anders T. Windsor
bare fyller på en ny rekke med bits om den har ledig plass, i begynnelsen
vil jo bufferne fylles opp, så vil den holde seg noenlunde konstant.
Forsåvidt en ralativt tungvint måte å gjøre det på. Men jeg skjønner hvor
du vil, og jeg var nok for kjapp i mine antakelser i begynnelsen, så jeg
vil gjerne dreie diskusjonen vekk fra akkurat dette, da jeg synes det har
blitt en blindvei.
Til mine andre spørsmål, toveiskommunikasjon er forsåvidt en god ide,
hvorfor gjøres ikke dette over firewire istedet/i tillegg? Og hvorfor skal

IEEE1349 er ikke en særlig etablert standard, koster mer enn s/pdif og
løser ingen reelle problemer for rene audioapplikasjoner.

Firewire i form av i-link løser poblemet digital overføring av mulitkanals
SA-CD / DVD-A.


Karl Erik Sylthe

[Anders T. Windsor]

Det det skulle eventuelt ha vært godt for, var å fylle opp bufferen kvikt
ved starten, og dessuten bedre feilkorreksjon, og det med buffer er jo
ikke ett problem, man lager jo bare bufferen så stor som den må være,
minne er ikke dyrt, spesielt ikke i forhold til forsterkerpriser, er
virkelig forskjellene så store at 10 sekund ikke holder? I så fall kan man
bare øke på, til 1 minutt, eller flere om man vil.

Men i alle tilfeller, jeg har ihvertfall fått svar på det jeg lurer på
angående akkurat denne delen av diskusjon, takk for input fra alle.

AtW

[Sverre Brubaek]

On Tue, 31 Aug 2004 00:07:02 +0200, "Anders T. Windsor"

Post by Anders T. Windsor
Det det skulle eventuelt ha vært godt for, var å fylle opp bufferen kvikt
ved starten, og dessuten bedre feilkorreksjon, og det med buffer er jo
ikke ett problem, man lager jo bare bufferen så stor som den må være,
minne er ikke dyrt, spesielt ikke i forhold til forsterkerpriser, er
virkelig forskjellene så store at 10 sekund ikke holder? I så fall kan man
bare øke på, til 1 minutt, eller flere om man vil.

Når man lager forbrukerelektronikk så teller hver cent. Jeg skal love
deg at ingen produsent legger inn noen komponenter ekstra siden 'de
koster så lite' 8MB minne vil spise en god bit av komponentbudsjettet
til en alminnelig CD-spiller.

Hvis du vil ha et inntrykk av hva komponentkostnader normalt utgjør,
så ta et alminnelig tastatur. (Koster ca 250-350 kr.). Total
komponentkost for dette, inklusive chassis, overstiger neppe $3-5.

Post by Anders T. Windsor
Men i alle tilfeller, jeg har ihvertfall fått svar på det jeg lurer på
angående akkurat denne delen av diskusjon, takk for input fra alle.
AtW

[Brynjulf Blix]

Post by Sverre Brubaek
Når man lager forbrukerelektronikk så teller hver cent. Jeg skal love
deg at ingen produsent legger inn noen komponenter ekstra siden 'de
koster så lite' 8MB minne vil spise en god bit av komponentbudsjettet
til en alminnelig CD-spiller.

Selv bærbare CD-spillere til noen 100-lapper har "risteminne" på 30-40
sekunder, og i denne tråden dreier det seg om keiserens nye CD-spillere.
Keiserens skreddere pøser nok gjerne på ekstra komponenter for noen tiere,
hvis de kan tjene noen tusenlapper...

Blix

[Sverre Brubaek]

Post by Brynjulf Blix

Post by Sverre Brubaek
Når man lager forbrukerelektronikk så teller hver cent. Jeg skal love
deg at ingen produsent legger inn noen komponenter ekstra siden 'de
koster så lite' 8MB minne vil spise en god bit av komponentbudsjettet
til en alminnelig CD-spiller.

Selv bærbare CD-spillere til noen 100-lapper har "risteminne" på 30-40
sekunder, og i denne tråden dreier det seg om keiserens nye CD-spillere.

Jo, men i det segmentet er dette noe du faktisk selger produkter til
massene på, samt at segmentet er stort nok til at man kan utvikle egne
chipsett for de.

Legg imidlertid merke til at det er ikke rå PCM data som blir lagret i
denne bufferen. Spilleren koder om til et mer økonomisk format slik
at de ikke trenger så stort minne.

Post by Brynjulf Blix
Keiserens skreddere pøser nok gjerne på ekstra komponenter for noen tiere,
hvis de kan tjene noen tusenlapper...

Keiserens nye CD spiller går i så små opplag at det ikke er økonomisk
forsvarlig å lage egne chipsett for disse. Dermed ender du opp med
masse komponenter for å hacke til en bufferløsning.

Det som vel har vist seg som oppskriften på å lage 'hi-end' er å bruke
helt standard design og kaplse det inn i en tung boks.

[Ketil Kirkerud Elgethun]

Post by Sverre Brubaek
Legg imidlertid merke til at det er ikke rå PCM data som blir lagret i
denne bufferen. Spilleren koder om til et mer økonomisk format slik
at de ikke trenger så stort minne.

Dette er noe du har gjentatt mange ganger - hvor har du det fra ?
Å implementere en eller annen form for (rimelig) transparent
signalkomprimering på 44/16-signalet virker på meg som _veldig_
mye dyrere, både i kretskompleksitet og strømbudsjett, enn å bare
kjøre det gjennom "litt" minne.


---Ketil

[Kjetil Torgrim Homme]

Post by Ketil Kirkerud Elgethun

Post by Sverre Brubaek
Legg imidlertid merke til at det er ikke rå PCM data som blir
lagret i denne bufferen. Spilleren koder om til et mer
økonomisk format slik at de ikke trenger så stort minne.

Dette er noe du har gjentatt mange ganger - hvor har du det fra ?
Å implementere en eller annen form for (rimelig) transparent
signalkomprimering på 44/16-signalet virker på meg som _veldig_
mye dyrere, både i kretskompleksitet og strømbudsjett, enn å bare
kjøre det gjennom "litt" minne.

min trufaste Technics-discman gjer lossy komprimering av signalet.
det er svært tydeleg å høyre på musikk med mykje høgfrekvent, uhm,
sus, utan rytmer -- f.eks. skrur eg helst av anti-ristefunksjonen når
eg høyrer på Biosphere. for normal rock og i normalt støyande
omgjevnader merkar eg ikkje forskjell.

[Sverre Brubaek]

On 31 Aug 2004 22:22:08 +0200, Ketil Kirkerud Elgethun

Post by Ketil Kirkerud Elgethun

Post by Sverre Brubaek
Legg imidlertid merke til at det er ikke rå PCM data som blir lagret i
denne bufferen. Spilleren koder om til et mer økonomisk format slik
at de ikke trenger så stort minne.

Dette er noe du har gjentatt mange ganger - hvor har du det fra ?
Å implementere en eller annen form for (rimelig) transparent
signalkomprimering på 44/16-signalet virker på meg som _veldig_
mye dyrere, både i kretskompleksitet og strømbudsjett, enn å bare
kjøre det gjennom "litt" minne.

La oss gjøre en antagelse om at vi relativt greit kan gjøre 1:3
kompresjon (transparens er oftest ikke et sterkt krav for
antiriste-funksjoner). Med 40 sekunder buffer får vi at vi trenger
56e6 bit lagring hvis det lagres rått, eller 19e6 bit komprimert

Hvis vi tar en alminnelig prosess (0.18um) så får vi plass til ca.
160-200000 bit/mm^2 med embedded 6T minne (SRAM) eventuelt kan man
røft sett greie ca 600-800000 bit/mm^2 med embedded 1T ram (DRAM), men
da må man ha ekstra logikk for refresh. De datamengdene vi snakker om
her er ca. i grenseland for hva som lønner seg for 1T ram.

Hvis vi antar 1T ram og ser bort i fra refresh betyr det at
differansen mellom komprimert og ukomprimert bufferstørrelse for 40
sek. blir 46mm^2. På et slikt areal kan man få plass til 4.5e6 gates
med logikk. Jeg gjetter på at en kompresjonskrets kanskje vil ta
5-10e3 gates...

Så konklusjonen blir nok at det er _veldig_ lønnsomt å komprimere data
for slike bufre.

Jeg gjetter imidlertid at kompresjonen er bedre enn 1:3.

[Sverre Brubaek]

On Mon, 30 Aug 2004 19:48:13 +0200, "Anders T. Windsor"

Post by Anders T. Windsor

Post by Sverre Brubaek
Du kan ikke operere med en asynkron klokke ikke uten at du aksepterer
å gjenta/hoppe over noen sampler (En kur som er værre en sykdommen).
En stor buffer hjelper deg bare umiddelbart etter at datastrømmen er
opprettet. Med en gang du når over/underrun får du de samme problemene
som om du ikke hadde buffer i hele tatt.

Ja, men å unngå under, og forsåvidt også overrun er jo veldig enkelt,
dessuten kan man enkelt unngå en forsinkelse ved å gota at avspillingen
starter før bufferen er fyllt opp, slik som på en pc, kombinert med at man

Den optimale bruken av en slik buffer vil være å starte avspilling når
den er halvfull siden du ikke vet om du vil gå mot en over eller
underrun.

Post by Anders T. Windsor
leser fortere enn man trenger (noe som er en bra strategi uansett, da det
vil forbedre mulighetene for feilkorrigering).

Å lese fortere enn redbook-CD spesifikasjonen i et system med s/pdif
tilkoplet dac vil garantere buffer overrun hvis du bruker en asynkron
klokke i DAC. Husk DAC har ingen mulighet til å be drivverket å pause

[Robert Aksland]

Post by Anders T. Windsor
On Mon, 30 Aug 2004 17:20:58 +0200, Robert Aksland

Post by Robert Aksland

Post by Karl Erik Sylthe

Post by Anders T. Windsor
Det er
vel bare å ta imot signalene, og deretter kjøre de gjennom dacen sin
klokke før det konverteres?

Såvidt jeg vet kreves det veldig stort buffer dersom DACen skal fullstendig
frigjøres fra klokkefrekvensen til innkommende signalstrøm.
Selvfølgelig mulig, men etter hva jeg har forstått gjøres det ikke i
praksis.
Kanskje fordi det vil gi for stor tidsforsinkelse?

Datastrømmen til en vanlig DAC holder ikke alltid samme hastighet.
Det avgjøres av klokken i utstyret som sender dataene. Dersom
utstyret som sender data har en ørliten langsommere datastrøm enn
DAC, så ville en DAC med fast klokke gått tom for data. Derfor må en
SPDIF-basert DAC regne ut en gjennomsnittshastighet for de asynkrone
(!) dataene den mottar. Hvor hørbart dette er kan diskuteres, men
effekten er der.

Jeg skjønner ikke helt hvorfor datastrømmen skal være tregere, det vil
jo påvirke sampling-raten i praksis, og det virker merkelig å lage en
leser som ikke klarer å lese data raskt nok til å oppfylle
spsifikasjonene til mediet.
AtW

Hele poenget er at det ikke er noen tilbakemelding fra DAC til
avspilleren. Dermed er det umulig for DAC å tviholde på sin egen
hastighet. Selv to identiske klokkechiper som er spesifisert likt vil
uavhengig av hverandre alltid bevege seg bort fra hverandre over tid. En
DAC er dermed helt avhengig av å justere sin egen hastighet til de
mottatte dataene, rett og slett fordi avsender ikke har noen måte å vite
om mottakers klokke på. Dette forhindrer effektivt at en SPDIF-basert
DAC kan ha sin egen konstante klokke.

[Anders T. Windsor]

Post by Robert Aksland
Hele poenget er at det ikke er noen tilbakemelding fra DAC til
avspilleren. Dermed er det umulig for DAC å tviholde på sin egen
hastighet. Selv to identiske klokkechiper som er spesifisert likt vil
uavhengig av hverandre alltid bevege seg bort fra hverandre over tid. En
DAC er dermed helt avhengig av å justere sin egen hastighet til de
mottatte dataene, rett og slett fordi avsender ikke har noen måte å vite
om mottakers klokke på. Dette forhindrer effektivt at en SPDIF-basert
DAC kan ha sin egen konstante klokke.

Jeg kan fortsatt ikke skjønne at dette skal være ett problem overhodet,
hva skiller lesing av audio-data fra lesing av vanlig data? Sånn jeg ser
det, ingenting, hvorfor ikke bare lese på samme måte som en cd-rom inne i
en datamaskin? Og man har en liten buffer, der man fortløpende lagrer
data, og bitsene sendes videre etter klokken som ligger i dacen?

AtW

[Robert Aksland]

Post by Anders T. Windsor

Post by Robert Aksland
Hele poenget er at det ikke er noen tilbakemelding fra DAC til
avspilleren. Dermed er det umulig for DAC å tviholde på sin egen
hastighet. Selv to identiske klokkechiper som er spesifisert likt vil
uavhengig av hverandre alltid bevege seg bort fra hverandre over tid.
En DAC er dermed helt avhengig av å justere sin egen hastighet til
de mottatte dataene, rett og slett fordi avsender ikke har noen måte
å vite om mottakers klokke på. Dette forhindrer effektivt at en
SPDIF-basert DAC kan ha sin egen konstante klokke.

Jeg kan fortsatt ikke skjønne at dette skal være ett problem overhodet,
hva skiller lesing av audio-data fra lesing av vanlig data? Sånn jeg
ser det, ingenting, hvorfor ikke bare lese på samme måte som en cd-rom
inne i en datamaskin? Og man har en liten buffer, der man fortløpende
lagrer data, og bitsene sendes videre etter klokken som ligger i dacen?

Ta to forskjellige CD-spillere, og sett på samme plate og start dem
samtidig. Det høres ut som en enkelt spiller til å begynne med, men
etterhvert vil du merke at det blir mer og mer ekko-effekt. Denne
forsinkelsen kan bli opptil flere sekunder på en hel plate, og en slik
forskjell er DAC nødt til å ta hensyn til. Det må mange sekunders buffer
til for å kompensere for forskjellig hastighet fra forskjellige
avspillere, og en slik forsinkelse vil gå for hardt utover
brukervennligheten til at noen implementerer det.

[Anders T. Windsor]

On Mon, 30 Aug 2004 19:36:16 +0200, Robert Aksland

Post by Robert Aksland

Post by Anders T. Windsor

Post by Robert Aksland
Hele poenget er at det ikke er noen tilbakemelding fra DAC til
avspilleren. Dermed er det umulig for DAC å tviholde på sin egen
hastighet. Selv to identiske klokkechiper som er spesifisert likt vil
uavhengig av hverandre alltid bevege seg bort fra hverandre over tid.
En DAC er dermed helt avhengig av å justere sin egen hastighet til
de mottatte dataene, rett og slett fordi avsender ikke har noen måte
å vite om mottakers klokke på. Dette forhindrer effektivt at en
SPDIF-basert DAC kan ha sin egen konstante klokke.

Jeg kan fortsatt ikke skjønne at dette skal være ett problem
overhodet, hva skiller lesing av audio-data fra lesing av vanlig data?
Sånn jeg ser det, ingenting, hvorfor ikke bare lese på samme måte som
en cd-rom inne i en datamaskin? Og man har en liten buffer, der man
fortløpende lagrer data, og bitsene sendes videre etter klokken som
ligger i dacen?

Ta to forskjellige CD-spillere, og sett på samme plate og start dem
samtidig. Det høres ut som en enkelt spiller til å begynne med, men
etterhvert vil du merke at det blir mer og mer ekko-effekt. Denne
forsinkelsen kan bli opptil flere sekunder på en hel plate, og en slik
forskjell er DAC nødt til å ta hensyn til. Det må mange sekunders buffer
til for å kompensere for forskjellig hastighet fra forskjellige
avspillere, og en slik forsinkelse vil gå for hardt utover
brukervennligheten til at noen implementerer det.

Ok, hvorfor ikke bare lese fortere enn du trenger? Da kan du kalre deg de
første sekundene med en mindre buffer, og forsinkelsen blir ikke
eksisterende, I tillegg trenger den totale bufferen å være mindre.

AtW

[Robert Aksland]

Post by Anders T. Windsor
On Mon, 30 Aug 2004 19:36:16 +0200, Robert Aksland

Post by Robert Aksland

Post by Anders T. Windsor

Post by Robert Aksland
Hele poenget er at det ikke er noen tilbakemelding fra DAC til
avspilleren. Dermed er det umulig for DAC å tviholde på sin egen
hastighet. Selv to identiske klokkechiper som er spesifisert likt
vil uavhengig av hverandre alltid bevege seg bort fra hverandre
over tid. En DAC er dermed helt avhengig av å justere sin egen
hastighet til de mottatte dataene, rett og slett fordi avsender
ikke har noen måte å vite om mottakers klokke på. Dette forhindrer
effektivt at en SPDIF-basert DAC kan ha sin egen konstante klokke.

Jeg kan fortsatt ikke skjønne at dette skal være ett problem
overhodet, hva skiller lesing av audio-data fra lesing av vanlig
data? Sånn jeg ser det, ingenting, hvorfor ikke bare lese på samme
måte som en cd-rom inne i en datamaskin? Og man har en liten
buffer, der man fortløpende lagrer data, og bitsene sendes videre
etter klokken som ligger i dacen?

Ta to forskjellige CD-spillere, og sett på samme plate og start dem
samtidig. Det høres ut som en enkelt spiller til å begynne med, men
etterhvert vil du merke at det blir mer og mer ekko-effekt. Denne
forsinkelsen kan bli opptil flere sekunder på en hel plate, og en
slik forskjell er DAC nødt til å ta hensyn til. Det må mange
sekunders buffer til for å kompensere for forskjellig hastighet fra
forskjellige avspillere, og en slik forsinkelse vil gå for hardt
utover brukervennligheten til at noen implementerer det.

Ok, hvorfor ikke bare lese fortere enn du trenger? Da kan du kalre deg
de første sekundene med en mindre buffer, og forsinkelsen blir ikke
eksisterende, I tillegg trenger den totale bufferen å være mindre.

Du vil da trenge en stor buffer fordi spilleren vil stadig komme lenger
og lenger foran DAC. Tiden på hvert spor blir helt feil, og CD-spilleren
vil bl.a fortelle at den begynner på nytt spor før sangen er ferdig å
spille. Og dersom du f.eks vil skifte spor så vil DAC spille videre på
sangen i X antall sekunder før sporskiftet. Dette er ikke en fornuftig
løsning. Det finnes ingen annen løsning enn at CD-spiller og DAC må
operere sammen, og så lenge det ikke er kommunikasjon tilbake, vil DAC
for alltid være slave av CD-spilleren med mindre en vil ofte
brukervennligheten totalt og tillate store tidsavvik.

[Karl Erik Sylthe]

Post by Robert Aksland
Det må mange sekunders buffer
til for å kompensere for forskjellig hastighet fra forskjellige
avspillere, og en slik forsinkelse vil gå for hardt utover
brukervennligheten til at noen implementerer det.

Var det noen som nevnte lip-sync...? ;-)


Karl Erik Sylthe

[Sverre Brubaek]

On Mon, 30 Aug 2004 19:14:13 +0200, "Anders T. Windsor"

Post by Anders T. Windsor

Post by Robert Aksland
Hele poenget er at det ikke er noen tilbakemelding fra DAC til
avspilleren. Dermed er det umulig for DAC å tviholde på sin egen
hastighet. Selv to identiske klokkechiper som er spesifisert likt vil
uavhengig av hverandre alltid bevege seg bort fra hverandre over tid. En
DAC er dermed helt avhengig av å justere sin egen hastighet til de
mottatte dataene, rett og slett fordi avsender ikke har noen måte å vite
om mottakers klokke på. Dette forhindrer effektivt at en SPDIF-basert
DAC kan ha sin egen konstante klokke.

Jeg kan fortsatt ikke skjønne at dette skal være ett problem overhodet,
hva skiller lesing av audio-data fra lesing av vanlig data? Sånn jeg ser

At det er snakk om audiodata er irrelevant. Poenget er at den som
forbruker dataene (DAC/prosessor) ikke kan regulere hastigheten på
produsenten (Drivverket)

Post by Anders T. Windsor
det, ingenting, hvorfor ikke bare lese på samme måte som en cd-rom inne i
en datamaskin? Og man har en liten buffer, der man fortløpende lagrer
data, og bitsene sendes videre etter klokken som ligger i dacen?

Hvis du tar en kikk på hvordan denne prosessen foregår i en PC vil du
finne at konsumenten (CPU/buskontroller i CDROM) kan gi beskjed
tilbake til produsenten (drivverket) at den må bremse/øke hastigheten.
(At CD spillere benytter en slik regulering er forresten grunnen til
at store tunge platetallerkener i CD spillere ikke bare er
meningsløst, men faktisk gjør hele spilleren _dårligere_)

[Anders T. Windsor]

Post by Sverre Brubaek
On Mon, 30 Aug 2004 19:14:13 +0200, "Anders T. Windsor"

Post by Anders T. Windsor

Post by Robert Aksland
Hele poenget er at det ikke er noen tilbakemelding fra DAC til
avspilleren. Dermed er det umulig for DAC å tviholde på sin egen
hastighet. Selv to identiske klokkechiper som er spesifisert likt vil
uavhengig av hverandre alltid bevege seg bort fra hverandre over tid. En
DAC er dermed helt avhengig av å justere sin egen hastighet til de
mottatte dataene, rett og slett fordi avsender ikke har noen måte å vite
om mottakers klokke på. Dette forhindrer effektivt at en SPDIF-basert
DAC kan ha sin egen konstante klokke.

Jeg kan fortsatt ikke skjønne at dette skal være ett problem overhodet,
hva skiller lesing av audio-data fra lesing av vanlig data? Sånn jeg ser

At det er snakk om audiodata er irrelevant. Poenget er at den som
forbruker dataene (DAC/prosessor) ikke kan regulere hastigheten på
produsenten (Drivverket)

Hvorfor gjøre ikke dette bare over firewire i alle tilfeller? Jeg er
forsåvidt enig i at toveiskommunikasjon er en bra løsning, da det også vil
føre til en, for praktiske formål, 100% feilfri overføring, i den grad den
ikke er feilfri i dag.

AtW

[Sverre Brubaek]

On Mon, 30 Aug 2004 19:54:21 +0200, "Anders T. Windsor"

Post by Anders T. Windsor

Post by Sverre Brubaek
On Mon, 30 Aug 2004 19:14:13 +0200, "Anders T. Windsor"

Post by Anders T. Windsor

Post by Robert Aksland
Hele poenget er at det ikke er noen tilbakemelding fra DAC til
avspilleren. Dermed er det umulig for DAC å tviholde på sin egen
hastighet. Selv to identiske klokkechiper som er spesifisert likt vil
uavhengig av hverandre alltid bevege seg bort fra hverandre over tid. En
DAC er dermed helt avhengig av å justere sin egen hastighet til de
mottatte dataene, rett og slett fordi avsender ikke har noen måte å vite
om mottakers klokke på. Dette forhindrer effektivt at en SPDIF-basert
DAC kan ha sin egen konstante klokke.

Jeg kan fortsatt ikke skjønne at dette skal være ett problem overhodet,
hva skiller lesing av audio-data fra lesing av vanlig data? Sånn jeg ser

At det er snakk om audiodata er irrelevant. Poenget er at den som
forbruker dataene (DAC/prosessor) ikke kan regulere hastigheten på
produsenten (Drivverket)

Hvorfor gjøre ikke dette bare over firewire i alle tilfeller? Jeg er

Jo IEEE1349 overføring vil elliminere behovet for å regenerere
klokken, men det er ikke hva vi snakker om. Vi har diskutert s/pdif
basert overføring.

Post by Anders T. Windsor
forsåvidt enig i at toveiskommunikasjon er en bra løsning, da det også vil
føre til en, for praktiske formål, 100% feilfri overføring, i den grad den
ikke er feilfri i dag.

Den er for alle praktiske formål feilfri i dag.

[Anders T. Windsor]

Post by Sverre Brubaek
Jo IEEE1349 overføring vil elliminere behovet for å regenerere
klokken, men det er ikke hva vi snakker om. Vi har diskutert s/pdif
basert overføring.

Ok, da misforstå jeg kanskje den oprinnelige teksten, mitt inntrykk var at
de mente at deneon sin I-link var en egen kabeltype, som eliminerte jitter
som var ett problem med firewire. Men uansett, det samme kan vel oppnåes
med s/pdif også? Sålenge det overføres digitalt så er det vel egentlig ett
fett åssen kabler man bruker.

Post by Sverre Brubaek

Post by Anders T. Windsor
forsåvidt enig i at toveiskommunikasjon er en bra løsning, da det også vil
føre til en, for praktiske formål, 100% feilfri overføring, i den grad den
ikke er feilfri i dag.

Den er for alle praktiske formål feilfri i dag.

Der er vi ikke uenig ihvertfall, jeg tror fortsatt at jitter også for alle
praktiske formål er uhørbart, men denne toveiskommunikasjonen har en
definitiv fordel, da kan vi omsider få slutt på at folk sier at
digital-kabler gjør store forsskjeller, og latterlige digitalkabler til
1000vis av kroner.

AtW

[Sverre Brubaek]

On Tue, 31 Aug 2004 00:10:42 +0200, "Anders T. Windsor"

Post by Anders T. Windsor

Post by Sverre Brubaek
Jo IEEE1349 overføring vil elliminere behovet for å regenerere
klokken, men det er ikke hva vi snakker om. Vi har diskutert s/pdif
basert overføring.

Ok, da misforstå jeg kanskje den oprinnelige teksten, mitt inntrykk var at
de mente at deneon sin I-link var en egen kabeltype, som eliminerte jitter

Det er vel sony som kaller det iLink (som bare er deres navn på
IEEE1349 aka firewire)

Post by Anders T. Windsor
som var ett problem med firewire. Men uansett, det samme kan vel oppnåes

At jitter er et problem med IEEE1349 m.h.p. audioapplikasjoner er bare
fri fantasi fra audioselgere uten nevneverdig kontakt med
virkeligheten.

Post by Anders T. Windsor
med s/pdif også? Sålenge det overføres digitalt så er det vel egentlig ett
fett åssen kabler man bruker.

I praksis ja, men s/pdif er da altså en enveiskommunikasjon som betyr
at mottageren må regenerere klokken av grensesnittet, noe man ikke må
med IEEE1349.

Post by Anders T. Windsor

Post by Sverre Brubaek

Post by Anders T. Windsor
forsåvidt enig i at toveiskommunikasjon er en bra løsning, da det også vil
føre til en, for praktiske formål, 100% feilfri overføring, i den grad den
ikke er feilfri i dag.

Den er for alle praktiske formål feilfri i dag.

Der er vi ikke uenig ihvertfall, jeg tror fortsatt at jitter også for alle
praktiske formål er uhørbart, men denne toveiskommunikasjonen har en

Enig.

Post by Anders T. Windsor
definitiv fordel, da kan vi omsider få slutt på at folk sier at
digital-kabler gjør store forsskjeller, og latterlige digitalkabler til
1000vis av kroner.

You wish...

Her er en saksing fra et ikke helt ukjent slangeolj... eh
kabelselskap:

"It’s a widespread misconception that all IEEE 1394 cables are alike.
Substandard IEEE 1994 cables can have performance problems that result
in poor performance just like regular A/V cables. Digital artifacting,
pixelization or choppy colored blocks can degrade video quality. Audio
can sound harsh with diminished soundstage or a lack of natural,
smooth sonic reproduction. The result is a less than enjoyable viewing
and listening experience.

<selskapets navn er fjernet>'s high bandwidth, high performance
FireLink 300 connection offers high speed hookup of audio/video
components with 1394 connections such as DVD players, digital
camcorders, digital VCRs and digital TVs. FireLink 300 delivers
improved overall performance with rich, vibrant color, razor sharp
detail, and crystal clear sound."

Post by Anders T. Windsor
AtW

[Lars Chr. Lura]

* Sverre Brubaek

Post by Sverre Brubaek
<selskapets navn er fjernet>'s high bandwidth, high performance
FireLink 300 connection offers high speed hookup of audio/video
components with 1394 connections such as DVD players, digital
camcorders, digital VCRs and digital TVs. FireLink 300 delivers
improved overall performance with rich, vibrant color, razor sharp
detail, and crystal clear sound."

Høres nesten ut som Zbafgre Pnoyr, det der. Heh, jeg tror jeg har både en
RCA/phono-, en SCART- og en optisk kabel fra dem (inkludert i prisen da
jeg kjøpte anlegget).

Jeg synes det er mye den samme svadaen som går igjen for alle produktene.

*google*

Jepp. Vant jeg noe nå? :)