Hi, ich habe einen Audio A/D-Converter entworfen. Dieser basiert auf dem CS5381 (AD) und CS8405 (Interface). Die Masterclock gibt momentan ein MK2703 (PPL) mit einem 27 MHz Quarz. Um den Jitter zu verbessern, möchte ich eine bessere Clock einsetzen. Ich habe mich dazu mit einen Audiophilen zusammengesetzt und mir wurden zwei Schaltungen empfehlen: 1. der XO (als DIY) von Guido Tent (ultra-jitter clock) 2. die KWAK-CLOCK von Elso Tent (Standard-Bauteile, trotzdem low jitter) Ich möchte das generierte Signal jedoch nun auch als Wordclock-Signal raussenden (damit der Wandler als Referenzclock agiert), aber auch ein WC-Signal empfangen, damit der Wandler als Slave getimed werden kann. Das eingehende WC-Signal soll dabei, auf Wunsch auf Basis der internen Clock, neu getimed werden. Den kompletten Vorgang kann man z.B. hier nachlesen: http://www.rme-audio.de/techinfo/steadyclock.htm Dort werden zwar auch FPGAs verwendet, aber ich denke nicht, dass man die gleiche Qualität erreichen wird. Leider fehlt mir das technische Know-How, diese Schaltung zu realisieren und ich muss daher auf vorhandene Chips zurückgreifen, die leider einen ziemlichen hohen Jitter haben :-( Aber vielleicht gibt es ja hier jemanden, der mir helfen kann :-) Ich habe hierzu mit einem Kollegen gemailt und möchte den Englischen Originaltext gerne quoten. Wenn ich ihn übersetze, könnten Fakten verloren gehen. Der Text ist jedoch keien Vorgabe, sondern nur seine Idee. Falls ihr andere Ideen habt, bitte posten! You simply use a VCXO which is fed by a PLL locked on the incoming bit clock. Except that instead of using an analog PLL, you implement digitally. So, your digital PLL will consist of : - a short FIFO going from digital input to audio DAC - a microcontroller - a control-DAC outputting a control voltage for the VCXO through a very low frequency cutoff lowpass filter. - the VCXO itself The control-DAC should be a cheap multibit chip, not a sigma-delta chip. You can implement everything in software inside the microcontroller, which gives you the opportunity to implement very fast locking. The controller can emulate a fast PLL which quickly finds the right voltage to put on the control-DAC to lock on the incoming signal. Then, the controller would switch to tracking mode, ie. it would keep the VCXO in sync with the incoming clock. This is the part which is hard to do in an analog PLL, because it must be very low noise. Here, there is no noise, as the PLL is implemented digitally. Thus it is a lot easier. However, the output levels of the control DAC are discrete. Thus, the incoming clock will always fall between two possible VCXO output frequencies, never being exact. This is not a problem, though : if the control-DAC is 16-bit, and sets the VCXO frequency to the closest possible frequency relative to the incoming signal, the frequency error is likely to be so small that it will only drift by a sample every few minutes. Therefore, the microcontroller should PWM the output of the control-DAC between two adjacent values at a very low rate, using the FIFO fullness as an indicator. For example, suppose the incoming signal is clocked at F, F being 44100 samples/s. Limited by the resolution of the control-DAC, the microcontroller can only set the VCXO frequency to either F+x or F-x. (a one-bit variation in the control-DAC output thus changes the VCXO frequency by 2x). A correct design should achieve a value x much lower than a hertz. Supposing a 16-bit control-DAC and a maximum error on the incoming clock in the 10s of hertz, x can be as low 0.001 Hz. So, the VCXO is set to F-x. It is slower than the incoming signal, thus bits will accumulate in the FIFO. When the FIFO contains, for instance, N bits more than half-full, the microcontroller switches the VCXO output to F+x. Now it is faster than the incoming signal and the FIFO will slowly empty. When it contains N bits less than half-full, the microcontroller switches back to F-x. I believe changing the VCXO frequency once every few minutes by such a small amount should be inaudible. And it has a very large advantage : all the input jitter is rejected, because the VCXO frequency stays constant most of the time. Viele Grüße Tobias
1.) Was für eine SampleRate verwendest du ? 2.) Wieso CS8405? Der ist am auslaufen ... stattdessen würd ich den CS8406 verwenden. 3.) Was für eine Anwendung ?
1) 44.1 kHz und 96 kHz (teilbar auf 48 kHz), 44.1 kHz ist aber bevorzugt 2) sorry, Schreibfehler - verwende in der Tat den CS8406 - danke! 3) hochqualitativer A/D-Wandler für den Studiobereich, der gesamte Analog-Buffer steht schon und ist getestet Der CS8406 bietet zwar Reclocking im Chip ab, allerdings möchte ich mir die Möglichkeit auf ADAT offenhalten. Daher muss das I2S-Signal direkt nach dem CS5381 passen. Falls das mit einem FPGA zu kompliziert ist, muss ich einfach einen 74VHC4040 oder 74VHC74 für asynchrones Reclocking nehmen.
Also normalerweise wirds so gemacht, dass zum analogen Audiosignal noch zusätzlich ein Sync-Eingang hast, auf das dann "getriggert" wird. Und zwar aus dem Grund, dass das ganze Studio mit dem gleichen Takt läuft. Ob das jetzt nun wirklich genau 48kHz sind oder 47.99kHz ist egal, nur gleich sollte es sein.
Vorab: Bin was Studiotechnik angeht kein Newbie. Aber Du kannst natürlich alles ausführlich schreiben, damit andere Leute im Archiv den Text besser nachvollziehen können. Bei uns im Studio haben wir 3x RME ADI-8 DS und 2x die HD-Protools Wandler. Die ADI-8 DS sind über die Digital-ADAT-Bridges des HD-Protools-System verbunden. Ein ADI-8 DS gibt den Takt an, alle anderen Geräte richten sich danach (auch der Lexicon 480L und die Delays). Der Vorteil der ADi-8 Geräte ist, dass sie ein empfangenes Sync-Signal auf Wunsch reclocken können. Wenn das andere Geräte also "nicht im Takt" ist, wird es durch die interne Clock wiederhergestellt. Klar, im Multi-Gerte-Betrieb könnte dies asynchron werden, aber gehen wir mal davon aus, dass es kein anderen Geräte gibt. Wie würdest Du ein eingehendes Clocksignal vernünftig reparieren. Eine interne, jitterfreie Clock steht Dir zur Verfügung. Viele Grüße Tobias achja: 48 kHz bzw. 96 kHz verwendet man eigentlich nur bei Broadcasting. Musikproduktion (mit Ziel 44.1 kHz) wird im Großteil der Studios auch kompltt auf 44.1 kHz produziert. Der klangliche Unterschied zu 48 kHz ist fast nicht nachvollziehbar, die Prozessorlast ist höher und es treten Probleme bei der SRC zu 44.1 kHz auf.
@Tobias: kannst du die Probleme bei der SRC mal etwas genauer beschreiben. Ich beschäftige mich gerade mit der Thematik und ein paar Erfahrungen aus der Praxis wären da nicht schlecht. Danke, Heiner.
Ok, bin in der Broadcast-Abteilung =). Bei uns wird das Reclocking direkt im Chip gemacht, da bei uns ADAT eher die Ausnahme darstellt. D.h. der Clock des A/D-Wandlers läuft auf Slave-Mode ... wie alle anderen auch, bis auf den Codec, der den Takt auf dem Sync generiert. Jitter weiss ich nicht auswendig, könnte ich aber am Montag mal nachschauen. Ist aber sehr bescheiden, was ich in Erinnerung habe. Wie du verwenden wir auch meistens die Chips von Crystal, werden in nächster Zeit aber mal die Codecs von Wolfson ausprobieren. Von den Werten schauen sie gut aus, kosten aber um einiges weniger. mfg Kriki
Hallo Heiner, ich bin leider kein Tontechniker, kann dir die Probleme also nicht wirklich technisch erklären. Ich kann aber gleich mal einen Kollegen anschreiben, der mehr Ahnung davon hat. Generell ist es so, dass Sample Rate Conversion (SRC) immer vermieden werden soll. Durch Up- und Downsampling ungrader Werte immer was dazugedacht oder weggelassen werden muss. Das Signal wird dann durch verschiedene Digitalfilter gejagt. 96 kHz / 2 = 48 kHz (Hälfte wird weggelassen, aber sychron) 48 kHz * 2 = 96 kHz (Interpolation, Zwischenwerte müssen ausgedacht werden) 96 kHz / 44.1 kHz = 2,1769 (asynchron, u.a. wird auch die Phase beeinflusst) Auf der Website hier kannst Du Dir mal angucken, wie verschiedene Algorithmen arbeiten, ist nett gemacht: http://src.infinitewave.ca/ Viele "HighEnd" Fans sampeln das CD-Player Signal (44.1 kHz, 16 bit) meistens auf 96 kHz, 24 bit hoch, um eine bessere Signalqualität zu bekommen. Klar, THD+N und andere Werte verbessern sich bei aktuellen Chips, aber ich sehe noch nicht so den Sinn dahinter :-) Sorry, dass ich nicht helfen konnte :-( LG Tobias - tobwen@gmx.de
@Kriki: Ja, die Dinger von Wolfson kenne ich. Aber auf der anderen Seite gibt es auch wieder AKM, die nicht schlecht sind. Die Chips von Cirrus sind schon ewig draußen, kein Wunder, dass jetzt eine anderen Firma kommt, die bessere Werte hat. In ein paar Monaten kommen sicher wieder neue Chips von Cirrus und dann sind die wieder vorne. Das hört nie auf :-) Die ADI-8 DS haben ja auch ADAT, welches bei uns über die Protools-Bridges laufen. MMh, bei uns laufen die aber in 44.1 kHz. Ich glaube, dass ADAT nicht mehr auf 48 kHz nach unten beschränkt ist. Nach oben geht es ja dank S-MUX auch bis 192 kHz mittlerweile. Den Takt müssten ja folgende Dinger bekommen: Analog-Digital Seite: 1. A/D Wandler und 2. ADAT "Sender" oder 3. S/PDIF "Sender" (verfügt über internes Reclocking) Digital-Analog Seite 1. S/PDIF Empfänger (verfügt über internes Reclocking) oder 2. ADAT "Empfänger (kein Ahnung, ob der Reclocking hat) 3. D/A Wandler Grüße Tobias - tobwen@gmx.de
Hallo Tobias, ich durchschaue Dein Problem noch nicht so 100%ig. Geht es nur um eine Clock-refresh? Kannst Du nicht interne PLLs des FPGAs nutzen / digital übersamplen, um auf eine effektive Taktebene zu gelangen? Zwischenfrage: Mit "Viele "HighEnd" Fans sampeln das CD-Player Signal " meinst Du sicher die digitale Übernahme? Bei der analogen Übernahme ist das nämlich durchaus sinnig.
Na toll, habe mein Passwort vergessen und leider gibt es keine Recover-Funktion. Ja, es geht um ein Clock-Refresh. Siehe Website von RME. Ich kenne mich mit FPGAs gar nicht aus, das ist ja mein Problem. Die "HighEnd" Leute refreshen das S/P-DIF Signal mit einer externn, genaueren Clock, als das interne Gebamsel. Das "neue" Signal geht dann in den D/A Wandler. Viele sagen, es sei Voodoo... Grüße Tobias
Naja voodoo ist es wohl nicht. Beim DA-Wandeln ist es sogar recht unproblematisch, da man eigentlich nur puffern muss, um Reserve zu haben, eingehende Daten in unsteter Datenfolge an eine stabile clock domain mit steter Datenfolge zu übergeben. Eine Möglichkeit wäre, ein dual ported Ram im FPGA als fifo aufzubauen mit mit der unsauberen SPDIF einzuclocken. Da hier Datentakt und Systemtakt zusammenhängen, klappt das. Unter Umständen braucht man aber eine Taktregeneration. Abgeholt werden die Daten mit derselben Datenrate nur eben einem geglätteten Takt. Das Problem besteht aber dann, wenn die Datenströme auseinanderlaufen, man z.B. von einem unter mehreren Geräten nur 44099 samples bekommt, aber 44100 abgeben will. Dann muss man die Daten zuzusagen "ziehen" also pitchen. Dies funktioniert nur, wenn man hochfrequent resampelt und quasi analoge Werte bildet die mit einer neuen Zeitdomain abgesameplt werden. Im FPGA geht das aber recht gut, da es ausreichend schnell ist. Allerdings baut man damit immer ein/zwei samples an zusaezlicher Verzögerung ein, wenn man es genau machen will. Bliebe, aus einem unstabilen Takt einen geglätteten zu machen. Wenn man ein passendes Taktsignal hat, kann man eine interne PLL im FPGA nutzen. Das scheidet aber vermutlich aus, weil diese als Eingang gewisse Bandbreiten erwarten. Ich würde daher ein diskrete Lösung extern vorschlagen. Ansonsten bliebe, den Takt anhand einer Zeitbasis im FPGA auszumessen und einen eigenen Takt zu generieren, der im Mittel dieselben Samples/sec produziert, also nicht wegläuft und gleichzeitig aber immer noch synchron genug ist, daß ein als word clock slave laufender Empfänger den Datenstrom stets sauber erwischt. An einer Lösung für mein System arbeite ich gerade. Ein Grundproblem gibt es noch: Wann genau wirkt der Jitter? Wenn bereits die clock im Gerät unsauber ist, dann stimmen schon die zeitlichen Punkte einer AD-Wandlung nicht. Bei n=44100 und Analogwert=y(n) gibt es durch ein dn/dt auch ein dy/dt. Damit würde die Taktglättung vor einem DA überhaupt erst den Schaden anrichten. Dasselbe gilt bei der synchronisierten Übernahme in den Rechner. Hier hat man ja quasi ein resampling und pichshift pur. Umsowichtiger ist es, die Geräte von einem Master zu speisen und dafür zu sorgen, daß der Takt eine gute Signalqualtität hat: Mit verschliffenen Flanken hat ein reiner SPDIF slave durchaus seine Schwierigkeiten. Mein TASCAM-Pult mag meinen MINDPRINT-Wandler z.B. überhaupt nicht, weil er sich weich drauf synchronsieren will und es bei manchen Flanke nicht packt. -> glitches.
Yepp, ich stimme dir komplett zu. Interessant wäre ja herauszufinden ob eine FPGA, diskrete oder die interne Lösung der Cirrus-Chips (die können ja in den neuen Versionen auch Reclocking) besser sind. Wie Du schon richtig genannt hast, muss die Clock beim A/D stimmen. Ich habe jetzt eine ziemlich gute Clock entwickeln. Mein Problem ist ja jetzt, dass ich ein externes Wordclock-Signal ebenfalls nutzen möchte (wenn z.B. eine Masterclock im Studio vorhanden ist) oder diese ggf. auffrischen möchte (wenn sie z.B. gestört oder jitterhaft ist). Das Resampling, was Du ansprichst wird ja wieder in diesem "HighEnd" Bereich gemacht, ist aber im Studio gar nicht gerne gesehen. Da es sich natürlich um einen A/D handelt, könnte man gleich in 192 kHz aufzeichnen und dann auf 44.1 kHz "runterrechnen" (naja, passt nicht - Quantisierung halt wieder). Daher finde ich es besser, auf jeden Fall in 44.1 kHz zu arbeiten. Was Deine Mindprint-Wandler angeht: Ich habe ein Gewerbe und mal so ein Dingen für einen Kunden repariert. Ich habe daher Zugang zu deren Schaltpläne. Um die Geheimhaltung nicht zu gefährden, sage ich nur: BÄH! Billgster 74HCU04 Mist ... das Gehäuse und vermutlich die Support-Hotline sind das teuerste! Schreib mir doch mal ein Mail, vielleicht können wir uns austauschen und die Ergebnisse hier präsentieren. Viele Grüße Tobias - tobwen@gmx.de
Hallo Tobias, das *abo*-Zeichen bedeutet eigentlich nur mein Interesse an diesem Thread... Gruß Tom
naja, beschäftige mich auch grad' mit dem Thema Wordclock-Sync & SRC wie geht's denn nun praktisch ???
Aha, also um z.B. einen 8406 auf WC zu syncronisieren müsste man doch die WC x 256 multiplizieren. Und wie geht das ?? peter-sobisiak@arcor.de
Den Grund sehe ich nicht, aber Du kannst eine PLL nehmen, um den Takt hochzusetzen. Hast dann aber wieder Jitter!!!
Der Grund ist einfach: AES / SPDIF geht in den SRC; SRC & TX laufen auf WC Sync; AES geht dann in das nchfolgende Equipment (z.B. 'nen Digitalmixer). Der generiert auch WC. So die Idee. ???
hi, weis jemand obs einen audio AD wandler gibt, der direkt SPDIF ausgibt ? grüße
Sobi wrote: > Aha, also um z.B. einen 8406 auf WC zu syncronisieren müsste man doch > die WC x 256 multiplizieren. Und wie geht das ?? > peter-sobisiak@arcor.de Hallo, habe das für 48kHz WC mit einem 74HC7046 und einem GAL gemacht, läuft in einem SRC einwandfrei. Gruß, RN
Hallo Marcel, die meisten Audiowandler im Studiobereich geben, wie vin Dir gefragt, SPDIF ab. Für 200,- bis 400,- euro bekommst Du schon recht gute Systeme mit Sieh mal bei M-audio z.B. Die haben allesamt SPDIF , AES/EBU - ausgänge und word clock eingänge. ausserdem synchen sie sich auf Soundkarten und fremde SPDIF-Geräte. Ich benutzte z.B. den alten Mindprint AN/DI.
Bääh . .. die Mindprint machen ganz böse Jitter. Gaanz billige und schlechte Schaltungen.
hallo ich bin am überlegen, wie man alesis mod fx effektboxen (ModLink Port) via s/pdif (eher chinch als toslink) in eine daw einfügen kann....bräuchte einen d/d wandler, der auch die wordclock umsetzt. vielleicht auch gut für trashige buffer override fx? wer hat irgendwelche relevanten infos über modlink von alesis?
hi, ich klinke mich hier einfach mal ganz kurz ein: ich bin auch relativ neu in sachen FPGA (wie ihr anderen beiträgen im forum entnehmen könnt..) ich bin aber auch im Tontechnikbereich recht viel tätig. nun suche ich schon seit einiger zeit einen chip der mir ein ADAT signal in ein, am liebsten I2C signal und umgekehrz wandelt (muss nicht ein einziger chip sein) und der mir am allerliebsten noch die ADAT clöock in irgendeiner form extra ausgibt. ihr schreibt oben irgendwasvon ADAT.. weis da irgendwer was?
hi spiele auch mit dem gedanken eine genauere low jitterclock in meinem DAC zu verbauen ich bin einer derjenigen die ein 44,1kHz signal auf 96kHz 24bit aufsamplen :-) es gibt solche clock is den unterschiedlichsten formen und preisen ... sie ersetzen allerdings nur den ursprünglichen quarz zB Lclock : http://www.lcaudio.com/index.php?page=62 auch die der "Tent" reihe nur macht dies wirklich sinn ? es wird nur von optisch/koax digital in analog gewandelt grüße
An Tobias: Ist irgendwo eine Schaltung deines Wandlers erhältnich?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.