Jitter

[Zee]

Ik ben het helemaal met je eens JohanT.

Jitter wordt pas een probleem op het moment dat je het signaal naar analoog omzet. Sterker nog, als bv. een loopwerk veel jitter geeft, kan het signaal zelfs beter (=minder jitter) worden op het moment dat je het signaal van dat loopwerk bv. opslaat op hard disk en vanuit deze harddisk naar een DAC voert. Dit kan gebeuren omdat de harddisk minder jitter geeft dan het loopwerk. De jitter van het loopwerk is namelijk weer volledig 'verdwenen' wanneer je het bitpatroon opslaat op de harddisk. Alleen de jitter van de harddisk kan dan nog zijn slechte invloeden uitoefenen op het signaal wanneer je dat naar analoog omzet.

 

Dit is inderdaad fundamenteel anders dan bij analoge signaalverwerking waar elke schakel in de keten het signaal alleen maar verder kan aantasten. Bij digitaal kan het zelfs beter worden verderop in de keten! (zie ook het artikel van Bob Katz op digido.com)

 

De clock van de DAC kan ook geheel los staan van die van het loopwerk, mist de DAC een voldoende grote buffer heeft om altijd voldoende 'aanvoer' te hebben. In het geval je de complete CD eerst naar RAM in je DAC zou kopieren, dan is de enige component die nog jitter kan veroorzaken de fluctuatie in de frequentie van het kristal dat de clock van de DAC gebruikt. Jitter uit voorgaande schakels ben je dan geheel kwijt.

[erik klijnsmit]

astenblaft

 

zit dit ook allemaal in mijn harman karton

[SpeedyAndr]

Geplaatst door erik klijnsmit:

astenblaft  

 

zit dit ook allemaal in mijn harman karton      

 

Nee niet alles, luister maar eens goed naar dat ding

Gisteravond hebben we het tegendeel bewezen, een Marantz cd6000 ose klonk toch wel h

[Kermit]

Fijn voor je dat je nu wel verschil hebt gehoord. Maar dat zegt nog niet zoveel: misschien hoor je die verschillen ook als je die Marantz naast de Harman Kardon super special van erik zet....

 

Ach, maar dit is natuurlijk off topic (net als jouw bericht) en daar reageer je natuurlijk niet op..

[void]

Geplaatst door JohanT:

 

Dan ben ik het niet helemaal met je eens    

 

De timing komt van de klok in de CD-speler.  Data wordt in het loopwerk gebufferd voordat deze naar buiten wordt gestuurd. Een goede klok bestaat uit een kristal, dat vrijwel onafhankelijk hoort te zijn van externe invloeden (voedingsspanning, mechanische verstoringen, etc.). Natuurlijk komen de bitjes niet altijd keurig op een rij de lees-unit uit, maar daarom worden ze in het loopwerk ook gebufferd. Zolang de klok die de buffer controleert maar stabiel is, is er niets aan de hand.

 

Elke redelijke DAC kan locken op het binnenkomende 'gejitterde' signaal en een nieuwe klok genereren, die correcties vinden geloof ik hooguit zo'n 10x per seconde plaats, maar je kunt niet realtime jitter corrigeren (al dan niet met hulp van een buffer), dan zou het met 11.2896MHz of vaker moeten plaatsvinden. De meeste soorten jitter valt er niet meer uit te halen.

[JohanT]

Geplaatst door void:

 

maar je kunt niet realtime jitter corrigeren (al dan niet met hulp van een buffer), dan zou het met 11.2896MHz of vaker moeten plaatsvinden. De meeste soorten jitter valt er niet meer uit te halen.

 

Leg me dat nu eens uit. Zolang het signaal digitaal blijft is er volgens mij niets aan de hand. Over welke "soorten" jitter heb je het, en waarom is dat volgens jou een probleem zolang je niet naar het analoge domein gaat? Geef eens een voorbeeld, zodat het wat duidelijker wordt? Het is me echt niet duidelijk wat ik mis.

 

Bedankt voor je reactie!

 

Johan

 

P.S. overigens is clock recovery op een 11 MHz manchester encoded signaal niet echt spectaculair.

[SpeedyAndr]

Geplaatst door Kermit:

Fijn voor je dat je nu wel verschil hebt gehoord. Maar dat zegt nog niet zoveel: misschien hoor je die verschillen ook als je die Marantz naast de Harman Kardon super special van erik zet....    

 

Ach, maar dit is natuurlijk off topic (net als jouw bericht) en daar reageer je natuurlijk niet op..

 

Voor deze ene keer dan:

Hans en z'n broer vinden de Northstar zelfs mooier klinken dan een aantal (ooit) referentie spelers zoals de ML 39, div. Wadia en nog een paar

Ook ik verkoos hem boven een Wadia.

 

Dit zegt nog steeds niet alles, maar mij zegt het wel meer dan Erik's en mijn oordeel over de welbekende vergelijkende test onder de welbekende niet-optimale condities toen we het ff snel tussendoor vergeleken

 

Andr

[JohanT]

Geplaatst door JohanT:

 

Leg me dat nu eens uit. Zolang het signaal digitaal blijft is er volgens mij niets aan de hand. Over welke "soorten" jitter heb je het, en waarom is dat volgens jou een probleem zolang je niet naar het analoge domein gaat? Geef eens een voorbeeld, zodat het wat duidelijker wordt? Het is me echt niet duidelijk wat ik mis.  

 

Ik zal nog een keer uitleggen wat ik bedoel. Dan is het waarschijnlijk ook duidelijker of ik iets over het hoofd zie.

 

In de datacommunicatie wordt jitter (variabele vetraging) meestal op de volgende manier te lijf gegaan:

 

1. de receiver heeft een interne klok, die onafhankelijk is van de input.

2. in het input signaal is de transmitter klok gecodeerd (manchester encoding).

3. in het input-circuit van de receiver wordt de data naar een fifo geschreven, met behulp van een PLL klok. De output klok van het PLL circuit is gesynchroniseerd met de klok in het inputsignaal.

4. de receiver leest de data uit de fifo met behulp van de device klok.

 

Hierdoor elimineer je faseverstoringen in het inputsignaal. Wel introduceer je daarmee latency, wat een reden is dat de bovenstaandee techniek niet zondermeer toegepast kan worden bij communicatie met zeer hoge snelheid. (lastig, die vertalingen naar het nederlands ). Bovendien heeft het kloksynchronisatiecircuit een insteltijd. De echte data wordt daarom ook voorafgegaan door een preamble.

 

Wat ik niet begrijp is waarom deze techniek in de digitale audio niet zou werken. In de datacomm hebben we natuurlijk het voordeel dat we uiteindelijk niet naar een analoog signaal hoeven te luisteren. Anderszijds wordt daar met veel hogere snelheden gewerkt. Dus volgens mijn (leken)mening zouden digitale audio designers eens moeten kijken naar high speed switching ontwerpen.

 

Ik heb in het bovenstaande een aantal belangrijke technische details weggelaten, maar ik hoop dat ik het principe in ieder geval duidelijk heb weergegeven. Wie kan mij uitleggen of het bovenstaande inderdaad ook toepasbaar is in de audiowereld (ik ben een leek op dat gebied), en zo niet, wat ik over het hoofd zie? Bedankt!

 

Johan

 

P.S. ik wil niet drammerig klinken, maar ik begrijp het probleem werkelijk niet. Ligt zoals altijd waarschijnlijk aan mij

[void]

Geplaatst door JohanT:

 

Leg me dat nu eens uit. Zolang het signaal digitaal blijft is er volgens mij niets aan de hand. Over welke "soorten" jitter heb je het, en waarom is dat volgens jou een probleem zolang je niet naar het analoge domein gaat? Geef eens een voorbeeld, zodat het wat duidelijker wordt? Het is me echt niet duidelijk wat ik mis.    

 

Bedankt voor je reactie!

 

Johan

 

Zoals al eerder gezegd in deze topic is het langzamerhand duidelijk geworden dat de AES/EBU en SPDIF interfaces een enorme blunder zijn qua ontwerp. De klok en de data van het L/R kanaal worden verenigd in een bitstream, bij aankomst moet er een tijdas gecreeerd worden uit deze data, maar de reconstructie ('clock recovery') blijkt totaal niet te vertrouwen. Het blijkt onmogelijk alle jitter te elimineren, dus ben je afhankelijk van loopwerken en kabels van hoge kwaliteit (en klinken CD-R's slechter dan het origineel).

 

Waar dat precies aan ligt wordt vrijwel nergens duidelijk uitgelegd, ik ken talloze sites die uitgebreid jitter behandelen en meettechnieken en jitteranalyses maar vrijwel nergens wordt ingegaan op de kern van het probleem, er is trouwens ook nog veel onderzoek naar. Jitter is complexer als op vele websites zogenaamd wordt uitgelegd, er bestaan veel misverstanden over. Ik ben zeker geen expert en kan alleen in eenvoudige bewoordingen vertellen wat ik ervan begrijp.

 

Bij reclocken neem je de gemiddelde timing van de binnenkomende pulsen, om het gemiddelde te bepalen moet je een grote serie pulsen meten, maar daarmee filter je dus maar jitter in een beperkte bandbreedte.

Er is een heel spectrum aan jitter, o.a. Stereophile publiceert tabellen bij reviews, niet dat dat veel zegt over hoe het klinkt, maar voor sommige soorten zijn we gevoeliger voor dan andere. Het probleem is niet om een strakke reclock te maken maar om te weten waar het originele kloksignaal vervormd is.

 

Stereophile - A Transport of Delight: CD Transport Jitter (begin en einde zijn wel interessant)

 

Understanding and Performing Precise Jitter Analysis (geeft een idee hoe complex het is om Jitter te analyseren)

[JohanT]

Bedankt voor je reactie!

 

Geplaatst door void:

 

Zoals al eerder gezegd in deze topic is het langzamerhand duidelijk geworden dat de AES/EBU en SPDIF interfaces een enorme blunder zijn qua ontwerp. De klok en de data van het L/R kanaal worden verenigd in een bitstream, bij aankomst moet er een tijdas gecreeerd worden uit deze data, maar de reconstructie ('clock recovery') blijkt totaal niet te vertrouwen.

 

 

De data van de receiver synchroniseren met de klok in de inputstream is heel gebruikelijk in de datacommunicatie. Ik begrijp niet waarom dat in de audiowereld ineens niet te vertrouwen is. Voor meer informatie over dit onderwerp: kijk eens pp Google naar manchester encoding.

 

Het blijkt onmogelijk alle jitter te elimineren, dus ben je afhankelijk van loopwerken en kabels van hoge kwaliteit (en klinken CD-R's slechter dan het origineel).

 

Het is de vraag of het nodig is om alle variatie te elimineren. Zolang de signaalovergangen binnen een bepaald interval plaatsvinden, zie ik geen probleem. Maar hier kijk ik weer met mijn databril op. CD-R

[seoman]

Het verschil tussen audio en data is tijd.

Dat je byte een minut later binnen komt dan dat je wil is voor data jammer maar voor audio ronduit k*t. Verder is er geen 2 weg kommunikatie bij audio.

 

Er zitten in audio & video componenten geen fifo of ring buffers. Dus is de tijd ineens heel belangrijk.

 

Verder: PLL zijn vreselijke dingen.

Onlangs op mijn werk ervaren wat een PLL voor een schade aanricht bij een varieerende ingangs frequentie.

Voorbeeld een dimmer.

Stel je wil fase aansnijden en je wil je produkt geschikt maken voor 50Hz en 60Hz wat doe je dan je gebruikt een PLL om je tellers te synchroniseren. Heel mooi en foute trigger signalen worden er uit gefilterd.

Kan niet beter zou je zeggen.

Ok sluit deze dimmer aan op een generator die ook een paar zware belastingen moet schakelen.

Wat gebeurd er er je belasting in geschakeld wordt? De diesel gaat langzamer dragen totdat de diesel het weer weg geregeld heeft. Dit duurt 10-15 perioden. Met als gevolg dat de PLL helemaal van slag is.

De schommeling is te lang om te negeren en te kort om goed te synchroniseren. Dus de fase aan snijding gaat helemaal fout.

Een simpele dimmer zou hooguit wat licht variatie geven om dat die alleen maar naar de spanning kijkt. Maar de PLL gaat uit en aan.

 

Ik kan mij voorstellen dat als het loopwerk hapert de informatie stroom stagneerd en daar door de PLL ontregeld of anders niet meer in de pas loopt met de informatie stroom. Nu moet de fout korrectie weer aan.

 

Zolang de klok gelijk loopt met de bits gaat 't goed. Maar dat gaat blijkbaar niet.

Wat ze hadden moeten doen is een composiet signaal moeten gebruiken voor 2draads verbindingen. Of gewoon de klok via een apparte draad. Maar dat is te duur

Glasvezel zou nog mooier zijn 3 golf lengtes; L, R en Klok. Nog duurder.

 

Groeten Simon

[JohanT]

Geplaatst door seoman:

Het verschil tussen audio en data is tijd.

Dat je byte een minut later binnen komt dan dat je wil is voor data jammer maar voor audio ronduit k*t.

 

 

Dat data een minuut later aankomt kan rampzalig zijn. Denk aan realtime toepassingen, of QoS. Maar ik geef toe dat het bij audio wat kritischer luistert. Daar staat tegenover dat er maar een heel kleine afstand te overbruggen is, en er (hopelijk) nauwelijks bagger over de lijn gaat.

 

Verder is er geen 2 weg kommunikatie bij audio.  

 

Er zitten in audio & video componenten geen fifo of ring buffers. Dus is de tijd ineens heel belangrijk.

 

Dat zijn volgens mij gewoon ontwerpbeslissingen. Men had best kunnen besluiten om de CD op 2x speed te laten draaien, data over te laten zenden met een acknowledgment, en ruimte te geven voor beperkte retransmissies.

 

<>

 

Ik kan mij voorstellen dat als het loopwerk hapert de informatie stroom stagneerd en daar door de PLL ontregeld of anders niet meer in de pas loopt met de informatie stroom. Nu moet de fout korrectie weer aan.

 

Als je de fluctuaties binnen de perken weet te houden, en slim met je buffer omgaat (je wilt helemaal geen lege buffer) zou dit geen probleem moeten zijn. Tenzij de CD echt problematisch is.

 

Zolang de klok gelijk loopt met de bits gaat 't goed. Maar dat gaat blijkbaar niet.

Wat ze hadden moeten doen is een composiet signaal moeten gebruiken voor 2draads verbindingen. Of gewoon de klok via een apparte draad. Maar dat is te duur  

Glasvezel zou nog mooier zijn 3 golf lengtes; L, R en Klok. Nog duurder.

 

De klok loopt altijd gelijk met de bits. De apparaten gebruiken alleen niet dezelfde klok. Overigens gaan door de meeste glasvezels ook signalen waarop de klokinformatie en data vervlochten zijn.

 

Johan

Groeten Simon[/QB]

[seoman]

Dat zijn volgens mij gewoon ontwerpbeslissingen. Men had best kunnen besluiten om de CD op 2x speed te laten draaien, data over te laten zenden met een acknowledgment, en ruimte te geven voor beperkte retransmissies.

 

Klopt dat zijn ontwerp beslissingen. En de verkeerde!

Maar de 2x speed optie had men toen nog niet de i2s waarschijnlijk wel

 

 

De klok loopt altijd gelijk met de bits. De apparaten gebruiken alleen niet dezelfde klok. Overigens gaan door de meeste glasvezels ook signalen waarop de klokinformatie en data vervlochten zijn.

 

Ja bij spdif ook wat heb je daar aan?

 

Die i2s bestaat al eeuwen toch wordt ie niet gebruikt. Ja binnen het loopwerk of da omzetter. Maar wat was 't voor een kleine moeite om die meteen standaard te maken.

Nu zitten we met de problemen.

 

Groeten Simon

[JohanT]

Geplaatst door seoman:

Nu zitten we met de problemen.

 

Dat is in ieder geval een heldere samenvatting

 

Johan

[Sebastiaan de vries]

Beste,

 

In de studio gebruikt men al jaren een los klok signaal. Weliswaar zitten l en r nog steeds in een data stream, maar het clock signaal van alle digitale apparaten in een studio wordt gevoed door een "masterclock". Zouden we dat in de huiskamer toepassen, dan zijn we al van een hoop ellende af. Maak van het loopwerk de masterclock, en voed het clock signaal apart.

 

S/Pdif is zoiezo een schande. De nieuwe 96 Khz aue/ebu2 standaard is een verbetetring. nu gaat het sinaal soor twee AES/EBU kabels. een data stream voor links, en een voor rechts. Het clock signaal gaat nog steeds apart van een masterclock naar de desbetreffende DAC.

 

jitter wordt nog cerder veroorzaakt de gemeenschappelijke 5 volt voedingsrail in spelers. Bijv. de bekende 74HCU04 ic hexinverter zorgt voor nog al wat hf rimpel op de voedingslijn. De clock zelf ook. Idealiter zou elke schakeling in het digitale circuit onafhankelijk en apart gevoed moeten worden. Wij hebben wel eens experimenten gedaan met elk ic, dac en clock apart te voeden met een 9v. batterij. spanning naar 5 volt gemaakt met spannigns deler. dat is echt eenw ereld van veschil. Helaas hebben wij nog neit de beschikking over een jitter meter, maar gehoordmatig, en meetbaar met de scope was dat al een grote stap vooruit.

 

Groeten,

Bas

[Gitaarwerk]

Beste bas, jou stukje is mooi

ook al eens eerder gepost..alleen nutteloos aangezien veel mensen de zoek functie niet gebriken van een forum.. (net als hifi.nl)