Hi, Ich möchte einen Audio-Algorithmus implementieren den ich vor einiger Zeit entwickelt habe, und hoffe auf Feedback ob mein HW-Entwurf dafür geeignet ist. Der algorithmus benötigt zwingend 32-bit floats (fixed point fällt wegen des Dynamikbereichs einiger berechnungne komplett weg), und ist ca. 50 Rechenoperationen lang (darunter unter anderem auch eine tanh berechnung sowie einige höhere Hochzahlen). Immoment habe ich folgendes vorgestellt: Ein Nexys2-1200-Board, darauf zwei Microblaze (mit FPU und 5x-Pipelining). Beide kommunizieren über einen(zwei) FSL-Bus. Der erste fungiert als Master und holt die l/r-Samples über PLB (A/D IP) rein. Der linke Kanal wird dann ebenfalls auf dem Master berechnet, der rechte Kanal wird auf den Slave ausgelagert. Danach werden die Kanäle wieder im Master zusammengefasst und über den PLB an einen D/A geschickt. Ich würde gerne mit 96khz fahren...Daten bekomme ich mit 24bit. Beide Microblaze laufen mit 90Mhz, genauso wie der PLB, etc. Meint ihr, das könnte klappen, oder sollte ich lieber doch auf eine (teure) DSP-Platform umschwenken?? Grüße, Stoney
> Meint ihr, das könnte klappen, oder sollte ich lieber doch auf eine > (teure) DSP-Platform umschwenken?? Du meinst, mit einem FPGA wärst du billiger dran? Wie kommst du darauf?
Lukas Steinert schrieb: > Ein Nexys2-1200-Board Naja das Board gibts für um die 100€, und hat eigentlich alles was man braucht...DSP-Boards sind da ja ungleich teurer...
Der ARM auf dem Beagleboard ist schneller als das was du vor hast, außerdem billiger und einfacher zu programmieren.
Das hatte ich als alternative auch schon im Auge, habe mich aber noch nicht wirklich damit auseinandergesetzt...wenn das aber, auch in verbindung mit externen A/D-D/A's zu empfehlen ist, werde ich mich da mal einarbeiten...
@Lukas Warum kommst du denn nicht um floating Point herum ? Was machst du genau ? Gehts darum Koeffizienten für einen Biquad auszurechnen ? Also Floatingpoint auf einem FPGA würd ich mir nicht antun wollen. Vor allem bringts gegenüber einem DSP recht wenig (zumal wenn der dann auch noch FP beherrscht).
@Rene: Ich müsste jetzt zwar etwas weiter ausholen, aber kurz gesagt: Der Algorithmus simuliert Trioden-Röhren, und ist so gut (eigenlob stinkt), das er zu 90-95% an die echten Röhren kankommt. D.h.: Röhren-Sound ohne Röhren. Das ganze mündet dann in einem Verstärker....wenn dieser Teil läuft, kommt noch ein 5 oder 10 Band parametrischer Eq. Gibt es denn bei den BeagleBoard eine Möglichkeit um Linux herumzukommen? Das brauche ich eigentlich nicht...wäre mir lieber das einfach nur in einem IDE zu programmieren...
Noch ein kleiner nachtrag zum Alrogithmus: Es kommen Prinzipbedingt (auf echten Bauteilwerten basierend) wegen der berechnung der phys. Größen zu sehr großen (10^12-10^15) als auch zu sehr kleinen Werten. Um dann noch eine ausreichende Genauigkeit zu bekommen, ist FP leider die einzige möglichkeit. Hab mich gerade nochmal umgesehen was es für möglichkeiten gäbe...aber jetzt bin ich nur noch mehr verwirrt...
@Lukas Das hört sich sehr interessant an. Und ist wahrscheinlich zugleich auch ne herausforderung. Ich meine Röhrensimulation ist ja immer vieldiskutiert. Ich gehöre zwar auch zu den Anhängern "Es-geht-nix-über-ne-echte-Röhre" :-)), aber Simulationen gegenüber bin ich auch nicht abgeneigt. Aber du weißt schon das FP nicht alles ist, das du bei FP auch nur so und soviel Genauigkeit hast (je nachdem ob single oder double), sprich wenn es bei großen Werten auf die letzte Nachkommastelle (z.b. 0.1 bei 10^12) ankommt das dir FP da auch nicht weiterhilft. Ich würde mal sagen das man denke ich alles auch in Fixpoint rechnen kann, nur wirds dann eben exponentiell häßlich :-) Ansonsten würd ich dir Blackfin/TI DSP irgendwie sowas empfehlen. Mit einem FPGA wirst du denke ich bei deinem Vorhaben nicht glücklich werden. Es sei denn du machst alles in Fixed Point. Aber dann hast du auch nur ca 80-100MHz je nach komplexität ...
@Rene Ahhh, ein Röhrenfreund =) Die ganze Anwendung an sich habe ich bei TubeTown ausgiebig diskutiert, finde aber gerade den Link nichtmehr..... Was FixPoint angeht...ich habe 2 Wochen lang vergeblich versucht den Algorithmus zu portieren in Matlab (da habe ich ihn auch entwickelt). Hier mal exemplarisch eine der Konstanten die in die Hauptberechung der Ausgangsspannung (Ausgangsignal) eingeht:
1 | a3 = mufix ^ 3 * rp * ( (2 * rp - rb)* strp^2 - rp*(rp+rb) * ktrp ) / (6 * (rp+rb) ^ 5 ); |
die r*-werte liegen so bei 62000-70000, mufix bei 100 und die anderen konstanten sind kleiner 1. In Matlab funktioniert es auch mit single-werten, aber wenn double-werte machbar sind, ist das sicherlich keine schlechte sache. Ich hatte mir ganz zu Anfang an die SHARC's angesehen, bevor ich hier den Audio-DSP mit Spartan 3-FPGA gesehen habe. Jetzt wirds wohl doch ein DSP g. Welche Serien würden denn Grundsätzlich in Frage kommen? SHARC wäre eigentlich so meine Wahl, weil ich auch noch VisualDSP hier habe...das ADSP-21369 EZ-KIT Lite wäre sehr fein, ist aber leider auch sündteuer :-(
Etwas was nur zu 2^-16 zum Klang beiträgt, kann auch weggelassen werden. (Die 16 ist exemplarisch und kann zwischen 8 bis 32 schwanken.) Wer Audio mit Festkomma nicht hinkriegt, macht was falsch. Das haben schone Generationen von Audiogeräten bewiesen die ohne Gleitkomma ausgekommen sind.
ne der bin ich nicht ^^ ... Das Problem das ich in Festkomma für diese Anwendung sehe, ist eben der Dynamikbereich...da ich physikalische Größen berechne (im Grunde basieren die Formeln auf den vereinfachten Elektronenströmen zwischen den Blechen in der Röhre. Da die Funktion nur linear ist, fitte ich dann noch tanh-funktionen um die Nichtlinearität zu modellieren. Das klappt sehr gut...allerdings habe ich eben intern sehr stark schwankende Größen, und muss das Ausgangssignal auch erst wieder Normalisieren weil mein Modell wirklich ~80Vss wie eine echte Röhre (je nach beschaltung) erzeugt. Damit bräuchte man wahrscheinlich sehr viele Vorkommastellen, was die Genauigkeit kaputt macht...
Hallo, hast du dir mal Gedanken darum gemacht, welchen Dynamik-Umfang deine Röhre bzw. die gesamte Elektronik eines Röhrenverstärkers hat. Tom
@Lukas Ich hatte dir eine PN geschrieben ... Also ich denke es muß auch in Integer machbar sein. Zur Not rechnet man halt mit 128x128Bit (seriell, also in mehreren Schritten). In einem FPGA könnte man dann diese serielle Riesenmultiplikation dann auch mehrfach laufen lassen um die Anzahl der Berechnungen zu minimieren bzw unabhängige Teile parallel berechnen zu lassen. Aber sehr interessantes Projekt. Muß ich schon sagen. Gruß Rene
@Rene Hab dir schon geantwortet. @Tom Ne noch nicht, ich meinte das auch bezogen auf den Algorithmus und die Funktionen der einzelnen Bleche etc.
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.