Moin moin! Ich habe "Angewandte Informatik" (Bachelor) studiert, war dann 3 Jahre als IT-Berater/Softwareentwickler berufstätig und habe mich dann entschieden doch noch einmal den Master in Informatik nachzuholen. Nun bin ich so weit, dass ich nur noch 2 Projekte vor mir habe und dann mit der Masterarbeit beginnen kann. Mit meinem Prof. haben wir uns darauf geeinigt einmal einen FPGA zur Signalverarbeitung auszuprobieren. Konkret geht es dabei um das Falten von Raumimpulsantworten mit einem Audiosignal, um hinterher eine Mehrkanal-Aufnahme zu erhalten. Das alles möglichst in Echtzeit und genau das wollen wir herausfinden, wie gut es eben funktioniert. Zu meinem Problem: Ich war bisher immer nur Softwareseitig unterwegs und habe leider nie im Leben von Anfang an einen Mikrocontroller oder FPGA programmiert. Mir fehlt sowohl das technische Verständnis als auch die Idee das hinterher umzusetzen. Wie und wo fange ich am besten an? Ich bräuchte vielleicht einfach nur ein paar Stichworte mit denen ich mich beschäftigen soll. Ob das jetzt am Ende in VHDL, Verilog oder Matlab/Simulink realisiert wird, soll erst einmal weniger die Rolle spielen. Mir geht es eher um solche Fragen wie: Wie ist so ein Entwickler-Board aufgebaut? Wie ist es dort mit einer ARM-CPU verbunden und wie steuern sich diese gegenseitig an? Wenn ich mit dem Programmer mein Programm auf den FPGA lade, wo ist es gespeichert und in welcher Form? Wenn ein Projekt auf dem Board fertig ist und es z.B. in der Industrie eingesetzt werden soll: Wie geht es da weiter? Es werden vermutlich keine Entwicklerboards mehr eingesetzt sondern nur noch der FPGA und...? Kann man einen FPGA mit einer CPU überhaupt vergleichen? etc. etc. etc. Wie Ihr seht, bin ich vielleicht kein einfacher Fall, ich möchte das aber auf jeden Fall durchziehen, es lernen und auch verstehen, wenn auch erst einmal nur Grundlegend und für das Projekt ausreichend. Gibt es gute Literatur hierfür? Dann brauche ich natürlich noch ein Entwickler-Board, am besten mit dem ganzen Zubehör, welches benötigt wird, also Stromversorgung, Programmierer etc.. Vielleicht eins, zu dem es auch viele Tutorials und Beispiele gibt. Bevorzugt wird hier von der Uni Xilinx, das ganze sollte die 1000€ Marke nicht überschreiten. Könnt Ihr mir da vielleicht etwas empfehlen? Ich brauche einen analogen Signaleingang, einen ADC und entweder acht DACs und analoge Signalausgänge oder eine Möglichkeit die acht Signale möglichst einfach und erweiterbar per Ethernet weiterzuleiten. Für etwas Einstiegshilfe und einen guten Rat bin ich immer sehr dankbar! Alex
:
Bearbeitet durch User
Gegenfrage: wieviel Zeit hast du dafür?
Alex H. schrieb: > Konkret geht es dabei um das Falten > von Raumimpulsantworten mit einem Audiosignal, um hinterher eine > Mehrkanal-Aufnahme zu erhalten. Deine Frage bezieht sich zwar auf alles was FPGAs zu tun hat, aber damit du überhaupt eine Chance hast, da irgendwo hin zu kommen, muss ich dich fragen, ob du die Aufgabe "falten von Raumimpulsantworten mit einem Audiosignal" schon gelöst hast. Also läuft dazu ein Prototyp, sind die Algorithmen bekannt, ist bekannt wie viel Speicher diese Raumimpulsantwort belegt etc. Gibt es schon eine Implementierung mit Integers oder ist das noch alles Float? Das Entwicklerboard brauchst du noch gaaanz lange nicht. Simulator genügt für dein Projekt für eine längere Zeit bzw. hat mehr Aussicht auf Erfolg. > Das alles möglichst in Echtzeit und > genau das wollen wir herausfinden, wie gut es eben funktioniert. Definiere "gut" :-) Performance/Watt Performance/Geld Entwicklungszeit Anzahl zusätzliche graue Haare des Entwicklers ... Alex H. schrieb: > Kann man einen FPGA mit einer CPU überhaupt vergleichen? Nein. Das wäre wie wenn man LEGO und Playmobil vergleicht. Zum Einstieg: https://www.mikrocontroller.net/articles/FPGA http://www.lothar-miller.de/s9y/categories/1-VHDL
Geplant war es bis Ende des Jahres zu schaffen. 2-3 Tage die Woche hätte ich Zeit dafür.
Alex H. schrieb: > Vielleicht eins, zu dem es auch viele Tutorials und Beispiele gibt. Da ich auch gerade (endlich mal) damit angefangen habe, mich mit dieser Technik zu beschäftigen: ein Tutorial oder Beispiel als allererster Einstieg ist gut. Aber danach beherzige Lothars Rat (den er mir in einer privaten Mail gab): das erste Projekt ist eine blinkende LED. Zieh das von vorn bis hinten durch, bis du jede Zeile darin verstanden hast. Als die LED blinkte, habe ich mich dann an ein analoges Fernsehsignal getraut, weil es einfach interessant klang, und habe die Bildschirmsteuerung meines vor 35 Jahren gebauten Z80-Computers nachimplementiert. Die zeigt nun zumindest ein "Hello world!" :-). Aber es war schon mal ein gutes Stück auf dem Pfad der Erkenntnis bis hierhin, und von DSP-Algorithmen bin ich damit immer noch ein ganzes Stück entfernt (wenngleich es sicher nicht der Anspruch ist, dort auch alles bis zur letzten Zeile zu verstehen). ps: Interessant, mit was für einer matschigen Bildschirmdarstellung man dazumals schon glücklich war. ;-) Das hier ist zwar nicht der originale Fernseher, den ich damals benutzt habe, aber wirklich besser war der wohl auch nicht.
:
Bearbeitet durch Moderator
Alex H. schrieb: > Geplant war es bis Ende des Jahres zu schaffen. 2-3 Tage die Woche hätte > ich Zeit dafür. Würdest du dich als mathematisch begabt bezeichnen? Digitale Signalbehandlung (Abtasten, FFT, FIR, IIR, Windowing, etc.) ist recht mathelastig und man sollte mathematisch schon recht fit sein, um die Ergebnisse interpretieren und die Algorithmen entsprechend anpassen zu können. Der FPGA ist dann die zweite Hürde, die es zu meistern gilt. Gruß,
Alex H. schrieb: > Gibt es > gute Literatur hierfür? Ja! Auch wenn es sich auf einen bestimmten Typ von FPGA und zumal einen SoC einschiesst, finde ich das Zynq-book gerade für Anfänger geeignet. https://all-med.net/pdf/the-zynq-book/ Vor den ganzen SoC-Theater war dies IMHO das beste Buch: https://www.pearson.com/us/higher-education/product/Wakerly-Digital-Design-Principles-and-Practices-and-Xilinx-4-2-i-Student-Package-3rd-Edition/9780131760592.html?tab=Features weil es eben Digitaltechnik und nicht allein FPGA-Gehampel lehrt. >Gegenfrage: wieviel Zeit hast du dafür? Ich würde diese wichtige Frage anders formulieren - Wieviel Zeit musst du unbedingt einplanen!? Es nützt nichts, sich für ein komplexes Thema, sagen wir mal 8 Wochen für alles, inklusive Einarbeitung, Schaffung Arbeitsumgebung einzuplanen aber dann wichtige Lernschritte (bspw. Simulationstaktiken, passendes IO-Constraining, Timing Closure techniques) auszulassen, weil sonst die Zeit nicht reicht. Ebenso ist es wenig zielführend sich gleich alles aufzubürden, bei dir klingt es stark danach, das ihr auch ein FPGA-Board selbst designen wollt - lasst das bloss bleiben wenn ihr in einem halben Jahr was brauchbares haben wollt. Ich würde als Minimum für einen Quereinsteiger aus der SW-Programmierecke als Minimum 3 Monate einplanen.
BAlex H. schrieb: > Ob das jetzt am Ende in VHDL, Verilog oder Matlab/Simulink realisiert > wird, soll erst einmal weniger die Rolle spielen. Genau das ist aber der Knackpunkt, an dem sich das Gelenk biegt. Denn wenn du mit Matlab möglichst abstrakte Modelle aufstellst und dann auf einem fertigen FPGA-Board am besten zusammen mit einem ARM darauf zum Laufen bekommen willst, dann bist du von der eigentlichen Hardware so weit weg wie die Sonne vom Mond, die zwar jeweils am Himmel leuchten, aber nie so wirklich zusammen. > Wenn ein Projekt auf dem Board fertig ist und es z.B. in der Industrie > eingesetzt werden soll: Wie geht es da weiter? Das kommt darauf an, wie sowas entwickelt wurde. Mit einem Eval-Board wird bestenfalls ein rudimentäres Funktionsmodell aufgebaut. Daran wird untersucht, welche Ressourcen benötigt werden, und darauf basierend wird ein möglichst punktgenaues, den Anforderungen genügendes Board entworfen, hergestellt und in Betrieb genommen. Und auf diesem Board wird das Projekt dann erst richtig fertig entwickelt. > Kann man einen FPGA mit einer CPU überhaupt vergleichen? Nein. Schon die Denkweise einer strukturellen, paralellen HardwareBESCHREIBUNGSsprache ist eine völlig andere als wenn ich eine prozedurale sequentielle PROGRAMMIERsprache anwende. Man sollte sich da nicht zu viel vom Traumsand in die Augen streuen lassen. > Kann man einen FPGA mit einer CPU überhaupt vergleichen? Das sind 2 völlig unterschiedliche Dinge. Man könnte zwar einen CPU-Kern in ein FPGA packen, der wäre aber einem dedizierten und optimierten CPU-Kern in sämtlichen Belangen (Strombedarf, Flächenbedarf, max. Takt,...) signifikant unterlegen. Nicht umsonst bauen FPGA-Hersteller einfach in die Ecken ihres Siliziums fertige CPU Blöcke. Denn diese CPU können nicht das, was das danebenliegende FPGA kann und auch nicht umgekehrt. Bürovorsteher schrieb: > Gegenfrage: wieviel Zeit hast du dafür? Das ist mir auch zu allererst in den Sinn gekommen. Jörg W. schrieb: > Aber danach beherzige Lothars Rat (den er mir in einer privaten Mail > gab): das erste Projekt ist eine blinkende LED. Zieh das von vorn bis > hinten durch, bis du jede Zeile darin verstanden hast. Samt Simulation... ;-) Hört sich zwar blöd an, eine blinkende LED zu simulieren, man lernt dabei aber fürs Leben. Aber dieser Weg ist ja der "HDL"-Weg, nicht der "Nimm-Matlab-und-per-Knopfdruck-wird-eine-VHDL-Beschreibung-draus"-Weg (eng verwandt mit dem bekannten chinesischen "Auspack-und-freu"-Weg... ;-)
:
Bearbeitet durch Moderator
Wenn ich soetwas machen müsste: Das Thema FPGA ist ganz schön umfangreich, bis Ende des Jahres ist es nur zu schaffen, wenn Du auf vieles "verzichtest". Als erstes würde ich in C/C++ die Algorithmen durchspielen: eine .wave-Datei einlesen, prozessieren, eine .wave-Datei schreiben. Das kannst Du jetzt schon anfangen. Als nächstes würde ich XILINX Vitis Software herunterladen und das Ganze in C/HLS/OpenCL nachimplementieren. Dann siehst Du auch, wo die Stolpersteine sind, wie die interne Struktur (MACs, Speicheranbinmung und so weiter) aufgebaut werden soll. Dazu musst Du keine einzige Zeile VHDL/Verilog schreiben. In der Zeit verstehst Du auch dann hoffentlich, worin der Unterscheid zw. dem FPGA und einer CPU besteht. Dann kompillierst Du Deinen Projekt als HW-Emulation. Du siehst die Simulation, kannst noch mehr erkennen, lernst auch dabei viel. Und wenn Du damit fertig bist (Ende des Jahres), kaufst Du Dir ein XILINX Board, z.B.: AVNET ULTRA96: https://de.farnell.com/avnet/aes-ultra96-v2-g/sbc-64-bit-arm-cortex-a53-r5/dp/3050481?st=Ultra96 oder ZCU104 https://www.xilinx.com/products/boards-and-kits/zcu104.html Du kannst dann immer noch .wav-Dateien von der SD Karte laden und processieren oder schließt eine USB-Soundkarte an (ist ja Linuxbasiert, also kein Problem)... Ist aber ein langer und beschwerlicher Weg. Du sollst Dir klar machen, was Du erreichen möchstest: Algorithmen verifizieren, Hardware-Implementierung, Echtzeit-Implementierung oder sonstiges. Alles zusammen wird kaum machbar Grüße Kest
Den Thread hier schon gesehen? Beitrag "Welches Zynq-Board für Mess-Applikationen ?" Das Thema ist ein Dauerbrenner. Das Zauberwort heisst: Fokussiere, Simuliere. Und du brauchst dafuer keine HW. Alex H. schrieb: > Ob das jetzt am Ende in VHDL, Verilog oder > Matlab/Simulink realisiert wird, soll erst einmal weniger die Rolle > spielen. Python/MyHDL schon in Betracht gezogen? Da findet man schnell einen Einstieg. Gibt es einige Tutorials (inkl. Synthese-Ausgabe im Browser). Alex H. schrieb: > Kann > man einen FPGA mit einer CPU überhaupt vergleichen? Der hier sorgt auch immer wieder fuer dieselben ausufernden Diskussionen. Klar kann man sie vergleichen, sollte man auch tun. Guck dir einfach mal an, was an harter Logik (Silicon) drinsteckt. Im Sinne von: "Fokussiere" wuerde ich mich halt eher mal fuer eins der beiden Themen, also entweder FPGA-Synthese oder Signalverarbeitung, dann aber auf DSPs, entscheiden. Du kannst natuerlich, wenn du von der Software her kommst, selber eine programmierbare DSP-Pipeline entwickeln, viel Schreibarbeit sparen und damit von beiden Tellerchen essen. Ist aber anspruchsvoller..
Bei mir ist das jetzt 10 Jahre her. Ich hatte mir ein Eval-Board (Xlilinx) besorgt, dazu Bücher zu VHDL, und was man alles so hier findet. Und dann bin ich die Beispiele in den Buch durch und habe die nachgebaut. Versucht etwas zu verändern und das Konzept zu verstehen. Das Konzept unterscheidet sich doch sehr zu einer Programmiersprache. Und es muss erst einmal Klick machen, das man Signale und Variablen unterscheidet und was alles bedeutet. Es gibt nichts, was mit einem sequentiellen Programm vergleichbar ist. Auch, dass man nicht losprogrammiert, sondern für alles erst einmal Testbenches schreibt, weil man nicht debuggen kann, Braucht eine gewisse Zeit. Bis es Klick macht, würde ich mal 3 Monate ansetzen.
Alex H. schrieb: > Geplant war es bis Ende des Jahres zu schaffen. 2-3 Tage die Woche hätte > ich Zeit dafür. Mal ganz ohne Witz: wie sieht es mit den Nächten aus? So manche Nuss habe ich erst nachts um 3 geknackt... ;-) Alex H. schrieb: > Konkret geht es dabei um das Falten von Raumimpulsantworten mit einem > Audiosignal, um hinterher eine Mehrkanal-Aufnahme zu erhalten. Das alles > möglichst in Echtzeit und genau das wollen wir herausfinden, wie gut es > eben funktioniert. Es ist also bereits mit "Offline-Berechnungen" z.B. anhand von Audiodateien nachgewiesen, dass das Verfahren prinzipiell funktioniert? Und es muss jetzt nur noch nachgewiesen werden, dass man das auch in Echtzeit kann und welcher Aufwand dafür nötig ist?
:
Bearbeitet durch Moderator
Vielen Dank für die zahlreichen Antworten! Ich hätte nicht gedacht, dass sich innerhalb so kurzer Zeit doch so viele - vor allem verschiedene - Antworten finden. Ich bin aktuell zeitlich (durch die bevorstehende Hochzeit meiner Schwägerin) sehr eingespannt und wollte nur Bescheid geben, dass ich erst kommende Woche dazu komme auf die ganzen Fragen zu antworten bzw. weitere Fragen zu stellen. Also bitte nicht böse sein oder denken ich antworte nicht mehr :). Also noch einmal vielen Dank bis hierher und allen ein schönes, langes Wochenende! Alex
Lothar M. schrieb: > Mal ganz ohne Witz: wie sieht es mit den Nächten aus? > So manche Nuss habe ich erst nachts um 3 geknackt... ;-) ja so manches Problem auf dem Bildschirm knackt man, sobald man nicht mehr auf dem Bildschirm starrt … Dieses Problemlösungsverfahren (Kontextwechsel) kann man beim FPGA easy anwenden, bspw indem man statt im VHDL-Code zu wühlen sich die reale Logic im Chiplevelviewer reinzieht. Oder mal einen (virtuellen oder realen) Logicanalyzer dranhängt. Oder als Einschlafhilfe ein paar Dutzend Seiten von den mehreren tausend Blättern Datasheets und Appnotes des FPGA-Herstellers liest. Oder,...
> Bis es Klick macht, würde ich mal 3 Monate ansetzen. Wer schon viel Hardwareentwicklung mit klassischer Technik gemacht hat, hat den Vorteil das es intuitiv Klick macht. 3 Monate brauchen eher die, die Probleme bislang in Software auf "normalen" Architekturen geloest haben. Das ganze mag mit einer HLS wohl einfacher implementierbar sein, aber ein FPGA-Entwickler ist man danach erst recht nicht. Spaetestens wenn man in der Industrie Projekte umsetzen will, muss die Implementierung nebenbei die noetige Effizienz, d.h. den angemessenen Umgang mit Ressourcen aufweisen. Da sieht es bei HLS doch immer noch ziemlich duester aus. Aber bei einem Forschungsprojekt mag das tragbar sein.
Lass die Finger davon, weil: - kaum jemand im Audio Bereich sowas in der Industrie auf einem FPGA macht => kein Job nacher - sehr spezialisiert => VHDL Stellen gibts nur in wenigen Ballungszentren - sehr aufwändige Einarbeitung => wird nicht fertig - kein Neuland => keine Anerkennung im akademischen Bereich
Alex H. schrieb: > Geplant war es bis Ende des Jahres zu schaffen. 2-3 Tage die Woche hätte > ich Zeit dafür. Das ist tatsächlich gar nicht so wenig Zeit. Wenn Ende des Jahres auch bei dir wirklich im Dezember liegt, dann ist das schon machbar wenn du schon weißt, was du machen willst. Also wenn du das eigentliche Problem der Signalverarbeitung schon z. B. in Matlab gelöst hast. Auch wichtig wäre das abzugrenzen was du alles nicht machen willst in der Zeit. Du willst in der Zeit kein FPGA Board selber designen. Du willst dich eigentlich gar nicht um die Hardware kümmern, sondern das in HDL schreiben, simulieren, gucken in welches FPGA das reinpasst und dann die passende Hardware kaufen. Und das kannst du alles schön kleinschrittig machen. Zuerst würde ich einige Zeit komplett Projektunabhängig VHDL lernen. Also Standardanfängeraufgaben lösen. Vielleicht sogar mit einem billigen FPGA Board weil das eben motivierend ist, wenn man da auch ein Ergebnis sehen kann. Aber trotz Hardware die Simulation nicht vernachlässigen. Wenn du dann etwas sicherer in der Hardwarebeschreibung und Simulation bist, also schon etwas Hardware denken kannst, dann kannst du anfangen die ersten kleineren Teile deiner Softwarelösung in VHDL zu beschreiben. Alles aussen herum, also die AD und DA Wandler und so, das beachtest du erstmal nicht. Da kommen die Daten aus einer Datei und werden wieder in eine Datei geschrieben in der Simulation. Das erweiterst du dann Stück für Stück um Komponenten die dir sinnvoll erscheinen. Wenn ich das richtig verstanden habe, dann machst du das mit dem FPGA zum Selbstzweck? Das ist völlig OK, mach das. Nur Mut, das ist ein sehr schönes Themenfeld das du da lernen möchtest. Die Lernkurve ist anfangs aber sehr steil wenn man tatsächlich HDL machen möchte und keine Hochsprache/Blockdesign aus Fertigbausteinen verwendet.
Martin S. schrieb: > Python/MyHDL schon in Betracht gezogen? Wozu? Eine Faltung ist eine Multiplikation mit den Eingangsdaten. Es braucht ein RAM für den Echtzeit-Input und einige mit den Impulsantworten, die er falten will. Dann ein FSM, die die Adressen steuert. Ganz ehrlich: Das schreibe ich in 2h hin. Simulieren, Verifizieren und anpassen auf das board maximal 1 Tag. Das Problem des TE ist weniger das FPGA, sondern dass er gar keine Übersicht über die Technologien und die Mathe dahinter hat. Und dann wäre noch die Frage, wie man die Impulsfiles bestimmt und berechnet. Die sind nämlich (aus dunkler Erinnerung) das Ergebnis einer umgekehrten Laplace-Transformation.
Weltbester FPGA-Pongo schrieb im Beitrag #6272364: > Ganz ehrlich: Das schreibe ich in 2h hin. Simulieren, Verifizieren und > anpassen auf das board maximal 1 Tag. Das Problem des TE ist weniger das > FPGA, sondern dass er gar keine Übersicht über die Technologien und die > Mathe dahinter hat. NB: Er will irgendwie damit anfangen. Da will man sich vielleicht nicht unbedingt mit einer Menge Tools, Programmiersprachen und deren Eigenheiten herumschlagen, damit man's dann nach 1-2 Monaten Einarbeitung in 2h hinschreiben kann.
Aber genau das wird er tun müssen, "sich mit einer Menge tools rumschlagen". Die technische Lösung besteht aus Wissen um Faltung (Mathematik), Elektronik (Auswertung der Wandler) und Programmierung (VHDL). Mit allen drei Dingen wird man sich befassen müssen. Zweckmäßiger wäre es, man knöpft sich erst mal die Mathe vor und löst das Thema in MATLAB, um den Hintergrund zu verstehen, arbeitet sich dann mit einem einfachen Beispiel in Elektronik ein, um AD-Wandlung, Filterung und Datenaquise zu verstehen und überlegt sich dann wie das alles mit VHDL erledigt werden kann. VHDL lernt man aber auch eher an einem einfachen Beispiel. Für alle drei Dinge sind eine Monate gfs aogr knapp, wenn man gar nichts weis. Diese kombinierten "Ich mache alles aus dem Stand"-Geschichten bleiben dann oberflächlich und löchrig.
Alex H. schrieb: > Wie ist so ein Entwickler-Board > aufgebaut? Solche Fragen z.B. zeigen mir, dass hier die falsche Person (IT-Berater) am falschen Thema dran ist. Der Umgang mit Elektronik ist wohl doch eher etwas für Studenten der Elektronik. Dort wird eigentlich alles rund um ADC, DAC und Signalverarbeitung geklärt. Warum sich jetzt die ITler dort noch einmischen und autodidaktisch mal eben ins Fachfremde stürzen, will sich mir nicht erschließen. Da kommt dann meisten eben wieder irgendeine von MATHWORKS automatisch zusammengeschossene C-Software aus dem Coder heraus, der mit viel Aufwand auf einen Prozessor gebracht wird, welcher sich in einem FPGA befindet, damit man "mal etwas mit FPGAs gemacht hat". Der Code ist dann umfangreich, langsam und unbrauchbar. Damit hat man das, worauf es eigentlich ankommt, nämlich eine Schaltung zu entwickeln, nicht einmal angekratzt. Quereinsteiger, die Cores in die Schaltung schmeißen und fett Silizium verbrauchen, gibt es im Markt auch schon genug :-) Mehr als genug !
Alex H. schrieb: > Konkret geht es dabei um das Falten > von Raumimpulsantworten mit einem Audiosignal, um hinterher eine > Mehrkanal-Aufnahme zu erhalten. Das war vor gut 20 Jahren der große Hit, einen Faltungshall zu applizieren, weil man hoffte, so an neue Klangdimensionen zu gelangen. Es war aber nur sehr kurz ein richtiger Hit, weil man schnell gemerkt hat, dass das nur mit trockenen, also reflexionsfreien Signalen funktioniert und auch dort nur begrenzt wegen der Artefakte, die die FFT mit sich bringt. Eine Sourrundaufnahme bekommt man damit schon gar nicht hin, weil immer derselbe Datenstrom dupliziert und manipuliert wird, während bei einer richtigen Raumantwort Reflexionen der Signale kommen, die ein Instrument zur Seite abstrahlt. Das ist also nur dann Dasselbe, wenn es ein Punktstrahler ist. Das ist aber nicht der Fall. Ein Orchester, ja schon eine einzelne Geige, strahlt in jede Richtung anders ab. Man kann sich das vorstellen, wie ein Spiegel an der Wand, in welchem man den Geiger von der Seite sieht. Das ist ein völlig anderes Bild, dass sich mit keinem Signalprozessor der Welt aus der Frontansicht ableiten lässt. Die Impulsfiles können das nicht leisten, wie man sich vorstellen kann. Diese müssen aber auch erst einmal prozessiert werden, was nur in der Theorie sehr einfach ist, praktisch aber auch wieder an der endlichen Auflösung der FFT scheitert. Ich würde daher zunächst mal auf Existentes zurückgreifen. Impulse files gibt es wie Sand am Meer. Bauen kann man das durchaus in DSPs, aber sehr fein und hochaufgelöst geht das nur in FPGAs mit sehr stark überlappenden FFTs, wie es ansatzweise hier dargestellt ist: http://www.96khz.org/htm/pitchmodule.htm Ich habe für einen solchen Fall ein VHDL-Modul entwickelt, da braucht es aber auch noch entsprechendes smoothing für die Resynthese des Signals.
Bitte 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.