Ich bekomme aus einem AC97 encoder chip ein digitales Signal mit 48kHz, das ich 44,1kHz umwandeln möchte. Mit einem FPGA sollte das machbar sein, ich frage mich aber, wie ich das am Besten angehe. Was mir bewusst ist, ist dass ich gfs etwas Bandbegrenzung einsetzen muss, was aber kein Problem darstellen sollte. Ich dachte an ein 20kHz Filter. So etwas habe ich schon implementiert. Mir geht es aber um eine geschickte Erzeugung des 44,1 Taktes. Im Grunde brauche ich eine PLL, die von 48kHz mit 441 auf 21,1 MHz übersetzt und einen Teiler 48. Mit dieser Datenradte liesse sich dann ein CIC Filter treiben, dass mit 480 zu 441 übersetzt. Lässt sich das in einem FPGA bauen?
Was du suchst, steht in der Xilinx Application Note XAPP514 http://www.xilinx.com/support/documentation/application_notes/xapp514.pdf und nennt sich Sample Rate Converter Chapter 22 ff, wenn ich mich jetzt nicht irre. Im schlimmsten Falle von außen einen Multiclock Generator PLL1700/1705/1706 (TI) oder etwas moderneres anbinden.
Die Prinzipien sind mir natürlich geläufig, aber es scheint komplizierter zu werden, als ich dachte. Wenn ich z.B. die asynchronous rate conversion verwende, müsste ich éinmal von der externen 48kHz auf meine interne Rate Konvertieren und dann nochmals auf die 44,1. Ich meine, es müsste wohl möglich sein, die interne domain so zu wählen, dass direkt 44,1 auszugeben sind, damit die Ratenkonversion nur einmal zu geschehen hat. Oder wäre es passender, die domain auf die externe zu synchronisieren?
Du brauchst beides, weil Dein Datentak ja von extern kommt. Ich würde zu einer stabilen Taktfrequenz des FPGAs raten, aus der die 44,1 zu erzeugen sind, oder falls nötig umschaltbar gehandhabt wird. Um eine echte Ratenkonversion wirst Du nur herumkommen, wenn Du die 44,1 hart an der 48 ausrichten kannst und darfst. Dann solltest Du die 44,1 auf den externen Takt synchen. Da kann man komplett im FPGA machen und auch für unterschiedliche Frequenzen einstellbar machen. Ich hatte mal dies hier realisiert: http://www.96khz.org/oldpages/frequencyconversion444896.htm Die Schaltung synchronisiert sich auf jeweils den Datentakt und stellt den digitalen Bittakt für s/PDIF passend in Frequenz und Phase ein. Es ist aber fraglich, ob das bei Dir geht bzw sinnvoll ist, weil der FPGA sicher noch andere aufgaben haben wird. Falls es gar kein FPGA sein muss, weil der nur dafür benötigt wird, gibt es heute auch Chips, die das direkt lösen und dies sehr gut, weil sie intern auf eine viel höhere Oszillatorfrequenz kommen und damit das Resampling über Taktdomämen hinweg genauer wird. Ferner gäbe es noch die klassische Studiolösung: Man wandelt das Signal der 48kHz auf analog und redigitalisiert es wieder. Das umgeht einige Probleme des Resampling und des Jitters. Kommt drauf an, was von vorne kommt. Wenn es ein AC97-Typ ist, hat der ja seine Bitclock, an die Du Dich dranhängen kannst. Mit etwas Gebiege kann man einen 25 MHz-Quarz so ziehen, dass eine nachgeschaltete PLL mit 29/59 genau den 12.8MHz Bittakt repräsentiert.
> Falls es gar kein FPGA sein > muss, weil der nur dafür benötigt wird, gibt es heute auch Chips, die > das direkt lösen und dies sehr gut, Das würde ich auch empfehlen: schnell realisiert, sehr preiswert, sehr hohe Funktionalität, erprobte Sache, garantiert fehlerfreie Funktion, z.B. SRC 4382, um nur mal eine Hausnummer zu nennen. Ich würde mir hier nicht das Leben schwerer machen, als es notwendig ist - außer dein Chef will es unbedingt. Der Zeitaufwand zur Realisierung unter Berücksichtigung der erforderlichen Designverikation dürfte sich wie 1 zu mindestens 1k verhalten.
Oder aber es ist, wie so oft und es muss was nachgerüstet werden, ohne ein redesign der Platine zu machen :-) Außerdem gibt es jaauch Quellen, wo man solche feinen Audio-VHDL-Sachen preisgünstig einkaufen kann :-D
Danke schon einmal für Eure Tipps. Wenn es einen Chip gibt, der das leistet, wäre das eine Alternative. Derzeit besteht aber die Intention, es im FPGA zu lösen. Ich habe aber nun noch ein anderes Problem: Ich musst / müsste auch die Umwandlung des codierten Datenstroms des AC97 coders leisten. Dieser liefert mir das Signal aber nur seriell im SPDIF Format. Das zu dekodieren sollte eigentlich einfach sein, dachte ich, aber ein Blick auf das Datenformat macht mich unschlüssig, wie ich da sicher einen Anfang erkennen kann. Das Datenformat ist so eine Art Manchester Code, falls das jemand kennt und hat im Wesentlichen 2 unterschiedliche Frequenzen, aber keinen Takt und keinen richtigen Anfang. Wahrscheinlich muss ich einfach etwas aufzeichnen und dekodieren um rauszubekommen, wo der Anfang ist?
Den Anfang eines Frames erkennt man an den drei gleichen Bits. Den Anfang des ersten Frames im Datenblock erkennt man an der "B"-Präambel. (Siehe http://www.hardwarebook.info/S/PDIF .) Zur Umwandlung von S/PDIF in etwas 'normales' wie I²S gibt es natürlich auch fertige Chips wie z.B. CS8416 oder WM8805.
So ganz bin ich da noch nicht durchgestiegen, aber auf den ersten Blick sind es einmal eine 000 und einmal eine 111 Folge. Die können aber doch in den Audiodaten ebenfals vorkommen?
Ein Audio-Bit wird als zwei Bits kodiert, von denen das erste immer den vorherigen Zustand invertiert; im Zweiphasenmarkierungscode sind drei gleiche Bits eigentlich nicht erlaubt.
PC-Verbinder schrieb: > Wenn es einen Chip gibt, der das > leistet, wäre das eine Alternative. SRC4192 von Ti oder ähnliche von Ti. Geht voll simpel und sogar mit angemessener Audioqualität ;)
Clemens L. schrieb: > Ein Audio-Bit wird als zwei Bits kodiert, von denen das erste immer den > vorherigen Zustand invertiert; im Zweiphasenmarkierungscode sind drei > gleiche Bits eigentlich nicht erlaubt. Das verstehe ich nicht. Ich dachte ich muesste erstmal die Bis dekodieren, dann fällt diese "Doppelfrequenzinformation" ja weg. Ich habe dann doch nur wieder die ursprünglichen Datenbits und da könnten doch 3 in Folge vorkommen ???
Der Frame-Anfang ist kein gülter Code und kann nicht dekodiert werden.
PC-Verbinder schrieb:
>Mir geht es aber um eine geschickte Erzeugung des 44,1 Taktes.
Mit einer PLL-Schaltung.
Einen VCO mit 44,1kHz aufbauen. Diese Frequenz durch 147 teilen = 300Hz.
Die 48kHz durch 160 teilen = 300Hz. Diese beiden 300Hz Frequenzen
mit einem Phasendetektor vergleichen. Die daraus entstandene Spannung
steuert den VCO. Der CD4046 enthält einen VCO und einen Phasendetektor.
Damit läßt sich das leicht realisieren. Man braucht dann nur noch
die Frequenzteiler.
Interessante Sache. Aber wie sieht das mit den Kosten aus. Kann ein FPGA gegen ca. 20€ für SRC4392 + Oszillator antreten? Hatte nämlich auch schon mal mit deinem Lösungsweg geliebäugelt. Und von einer PLL aka PLL17xx würde ich abraten. Das sind Jittergeneratoren. Damit machst du aus cd-Qualität fm-Radioqualität. Es sei denn, du reclockst das Signal wieder mit einem ASRC.
Hameg schrieb: > ca. 20€ für SRC4392 + Oszillator Aus eigener Erfahrung: mit einem guten Einkauf und einigermaßen Stückzahlen bekommt man den SRC4392 für unter 7€. Wenn ein reiner SRC ausreicht würde ich mal auf den SRC4190 bzw. SRC4192 schauen. Ersteren beziehen wir für ca. 2,5€. Naja und den Oszillator gibt es für wenige Cents...
Wenn bräuchte ich erstmal nur einen und müsste das board umbauen. FPGA wäre die bessere Lösung, wenn es nicht zu aufwändig ist.
Hameg schrieb: > Interessante Sache. Aber wie sieht das mit den Kosten aus. Kann ein FPGA > gegen ca. 20€ für SRC4392 + Oszillator antreten? Hatte nämlich auch > schon mal mit deinem Lösungsweg geliebäugelt. Wenn der FPGA ohnehin da ist, zahlt man quasi nur die Chipfläche für den Interface-Core und das ist minimal. Ein S/PDIf Interface in zwei Richtungen kostet je nach Komplexität (ohne Wishbone oder Businterfaces) rund 2k LEs bei Altera. Das sind anteilig eher 3-4 Euro. Extra einbauen wird man einen FPGA aber nicht. > Und von einer PLL aka PLL17xx würde ich abraten. Das sind Jittergeneratoren. Je nachdem, wie der FPGA eingesetzt wird, ist der Jitter ja ziemlich egal. Oder, man muss das Signal direkt treiben, dann muss sich der Jitter in Grenzen halten. Die SPEC nach S/PDIF einzuhalten ist bei einem aktuellen FPGA aber kein Thema.
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.