Hallo allerseits, für meine Abschlussarbeit benötige ich eine DSP-Plattform für Audiosignalverarbeitung. Der Algorithmus, den ich Implementieren möchte ist relativ rechenaufwändig und hat einen großen Speicherbedarf. Wunschanforderungen: 2 GByte RAM 3 MByte intern im DSP 250.000.000 Festkomma-MACs/Sekunde mit 64 bit breitem Akkumulator, oder 250.000.000 Gleitkomma-MACs/Sekunde mit 32 bit breitem Akkumulator 6 Ein- und 2 Ausgänge (I²S oder SPDIF oder Analog(24bit)) UART-Schnittstelle Das größte Problem ist wahrscheinlich nicht die Rechenleistung, sondern der rieseige RAM. Falls jemand eine Idee hat, wie ich anderweitig 500 MByte/s z.B. von einem RaspberrsPi oder einem Flash-Speicher in den DSP bekomme, könnte ich auf den externen RAM verzichten (die meisten Daten im RAM werden nicht verändert, sondern nur regelmäßig ausgelesen). Mindestanforderungen: 16 MByte RAM 375 kByte intern 25 MMACs/s Da wirds dann aber schon sehr unimposant. Darunter geht echt garnix. Habt ihr Empfehlungen, welches Board vo TI man da kaufen kann? Im Moment habe ich hier eines von Analog Devices vor mir, komme aber in keinster Weise mit der Entwicklungsumgebung zurecht. Wirklich in garkeiner Weise. Achso, da ich das Ding wohl privat finanzieren muss und echt pleite bin, sollte es nicht so megateuer sein. Eine Debug-Möglichkeit brauche ich nicht unbedingt. Dankeschöööööön!
Moin, Wie waer's mit einem stinknormalen PC und vielleicht noch ein..zwei Soundkarten oder USB Gedoens? Billiger wirstes wohl nicht kriegen. Gruss WK
Bandbreite zum RAM? Schon mal über einen FPGA nachgedacht? Wenn es von der Bandbreite und Latenz noch im PC reicht, wäre CUDA die erste Wahl. Wenn die Kanäle getrennt bearbeitet werden, dann währen mehrere kleine DSPs das Billigste.
Danke euch beiden für die schnelle Antwort! Ein PC ist leider ungeeignet, da ich sehr kurze Latenzen einhalten muss. Man kann es sich vereinfacht so vorstellen, als würde ein durchgehendes Audiosignal durch einen FIR-Filter gejagt. Dieser FIR-Filter wechselt ständig seinen Filterkern. Die Filterkerne sind so gestaltet, dass sie das Ursprungssignal nicht nennenswert verzögern, aber einen Nachhall erzeugen (Faltungshall). geschieht das Wechseln dieser Filterkerne mit größerer Latenz, als die Abarbeitung des FIR-Filters, stellt dies zunächst kein größeres Problem dar. Es verringert die Qualität des späteren Klangerlebnisses, aber der Algorithmus bleibt lauffähig. Die verschiedenen Filterkerne liegen im RAM und werden dann nur geladen. Ein Satz von Filterkernen (für alle Kanäle) ist etwa 2,2 MB groß und sollte für ein optimales Ergebnis etwa 200 mal pro Sekunde gewechselt werden (-->440MB/s). Wird seltener geladen, leidet die Qualität des Ausgangssignals. Theoretisch wäre es also auch möglich, die Filterkerne von einem kleinen PC bereit zu halten und (asynchron zum Sampletakt der Audiosignale) zum DSP zu schicken. Da wüsste ich aber nicht, mit welcher Schnittstelle man das machen könnte. Leider werden die Kanäle mehrfach durch den Algorithmus "vernetzt" weshalb eine einzelne Verarbeitung und Verteilung auf mehrere DSPs die Rechenleistung massiv erhöhen würde. Durch Runterschrauben der Anzahl von Eingangskanälen, der Samplingrate, erreichbarer Nachhallzeiten und Komprimierung der Filterkerne kann man eben noch einiges einsparen und landet dann irgendwann bei den Mindestanforderungen.
Ich befürchte fast, dass ich dir erst mal einen kleinen Dämpfer versetzen muss. Irgendwas ist hier faul bzw. würde ich diese Arbeit nicht annehmen. Warum musst du das Material aus eigener Tasche bezahlen? Du bist doch bestimmt an einer Uni, Institut, Unternehmen, die dir die technische Ausrüstung bereitstellen können? Die Aufgabe halte ich insgesamt für sehr anspruchsvoll. Ich würde diese Aufgabe übrigens auf einem FPGA lösen. Speicher müsste man extern anbinden, ist technisch aber möglich. PC könnte, wie schon von dir befürchtet, von der Latenz her kritisch werden bzw. nicht deterministisch genug (außer du willst auch noch viel Spaß mit Linux-Realtime Entwicklung haben). Allerdings wird das alles nicht total billig werden. Und obs das von TI gibt weiß ich auch nicht direkt. Zumindest die größeren/bekannteren FPGA Hersteller (Xilinx, Altera, etc.) haben durchaus FPGAs mit (optional) externem RAM und intern massig DSP-Einheiten.
Moin, das was du willst, gibt's nicht. Ich hätte sonst ein BF548-EZKIT mit SSD vorgeschlagen, aber wenn du schon mit dem ADI SDK nicht klarkommst (ok, VDSP++ mag peinsam sein), ist das wohl für die Füchse. Mit keinem der üblichen non-PC-Systeme schaffst du 500 MByte/s Durchsatz bei dem Addressierungsraum. Da solltest du wohl noch mal über die Bücher. Irgendwie macht dein brute-force-Ansatz so keinen Sinn... Und dass die Lehrstühle keine Plattformen stellen/vorgeben, klingt in der Tat sehr merkwürdig.
Michael B. schrieb: > Man kann es sich vereinfacht so vorstellen, als würde ein durchgehendes > Audiosignal durch einen FIR-Filter gejagt. Dieser FIR-Filter wechselt > ständig seinen Filterkern. Im FPGA geht das sogar während des Prozessierens einer Samplegruppe. In der Regel geschieht das ja allerdings nach einer Samplegruppe von daher braucht man nur die Quelle der Koeffizienten umschalten und das geht in jedem DSP. Man muss einfach auf den passenden Speicherbereich zugreifen. > das Ursprungssignal nicht nennenswert verzögern, aber einen Nachhall > erzeugen (Faltungshall). Wieder mal Faltungshall :-) Das ist eigentlich schon seit 10 Jahren wieder "out", weil man gemerkt hat, daß reale Hallszenarien sich nicht gut mit real aufgenommenem Material verträgt, weil dieses schon Reflektionen enthält. > Ein Satz von Filterkernen (für alle Kanäle) ist etwa 2,2 MB groß und > sollte für ein optimales Ergebnis etwa 200 mal pro Sekunde gewechselt > werden (-->440MB/s). Was soll das werden? Dynamische Parameterwechsel? Wenn ein Faltungshall wirklich das liefern soll, was in den Koeffizienten drin steckt, müsste man wenigstens 60ms prozessieren, damit das Ohr die entsprechenden Erstreflektionen auch korrekt auffassen kann. Richtiger Hall braucht darüber hinaus einige Sekunden an Laufzeit mit konstanten Verhältnissen (egal womit man es rechnet) ansonsten entstehen zufällige Reflektionen, die in keiner Beziehung zu einander stehen und einen völlig chaotischen Eindruck bringen. Der Zufallshall klingt zwar sehr interessant, erfordert aber sehr dedizierte prägnante Echos, um mit typischem Audiomaterial auszukommen und die kann man mit einfacher Synthese durch Verzögerung besser erzielen und dann hat dann nicht das Problem der Konvolution und der Fensterproblematik. Das Thema wurde damals in der Surround-Sound-Tonmeister-Gruppe diskutiert. Dort hatte damals auch EBS genau dazu Stellung genommen, die Effekte verdeutlicht und konkret auf einen Lexicon hingewiesen, der damit arbeitet. So richtig gut funktioniert Hall immer nur mit trockenen Signalen, weil Hall auf Hall unkontrollierte Echos generiert und der Soundprozessorentwickler ja den Primärhall nicht kennt. Daher ist das in den Consumer-Anlagen immer eine Spielerei. In der Produktion stellt man das letztlich auch nach Gehör und Wunsch ein und kann das Ergebnis kontrollieren, heute noch umsomehr, als das oft verhallte Samples verwendet werden, insbesondere bei Orchester- und Filmmusikproduktionen. Dort nutzt man Faltungshall allerhöchstens auf Einzelstimmen. Nur, wenn man Sounds generisch erzeugt, lohnen aufwändige und komplexe Effekte, da muss man aber sehr viel früher dran, als an die spätere Stereosumme. Ich habe da ja auch so meine Experimente hinter mir (Samplitude konnte das schon in der ersten Version, die wir in den spätern 90ern benutzt hatten) - später habe Ich das auch mal in einem FPGA gemacht, wo man sehr einfach falten kann - bin aber letztlich bei dem hier angelangt: http://www.96khz.org/htm/dynamicreverb.htm
Moin, Michael B. schrieb: > Ein PC ist leider ungeeignet, da ich sehr kurze Latenzen einhalten muss. Ich hab' nicht gesagt: Ein PC mit Betriebssystem, graphischer Oberflaeche, 42 Audio-Frameworks und -servern und Matlab/Simulink drauf. Aber ich bin mir sicher, dass du fuer das Geld, wo du heute einen PC von der Stange kriegst, nichts vergleichbares an Evalboards mit DSPs bekommst, was irgendwie in die Naehe deiner Rechen- und Speicheranforderungen kommt. Klar kannste irgendwelche FPGA-Boards fuer 4/8k Videogedoense hernehmen. Aber die werden tariflich sicher deutlich ueber irgendeinem Feldwaldwiesen-PC mit 'nem RAMRiegel und Audiokarte extra liegen. Wie sinnvoll das ueberhaupt ist und wie sinnvoll es ist, sowas als Abschlussarbeit zu machen, steht nochmal auf einem gaaanz anderen Blatt (Geheimtipp: Ich wuerd's nicht machen). Gruss WK
Es ist echt cool, mal mit kompetenten Leuten zu diskutieren! Das macht ja richtig Spaß hier mit euch. Ich hätte nicht gedacht, dass sich irgendjemand inhaltlich dafür interessiert, was ich mache. Danke! Leider kann ich euch noch nichts Genaueres erzählen. Aber ich kann Jürgen in so fern beruhigen, dass es sich nicht um den Faltungshall im eigentlichen Sinne handelt (aber sehr ähnlich). Ich freue mich schon jetzt darauf, wenn ich vorstellen kann, worum es sich handelt. Das Thema habe ich mir selbst ausgedacht. Mir ist klar, dass es recht anspruchsvoll ist, aber ich habe echt einen Riesenspaß daran. Und eigentlich geht es auch vorrangig um die Mathematik dahinter. Von der Aufgabenstellung her müssen nur kleine Teile des Algorithmus --zum Nachweis der Funktion-- implementiert werden, wofür der DSP, der mir zur Verfügung gestellt wurde ausreicht. Ich würde nur gerne nebenher das ganze auch in einer höheren Ausbaustufe Implementieren, weil es wirklich ein wahnsinnig abgefahrener Effekt ist. Meine Betreuer im Fachgebiet sind total goldig und unterstützen mich ganz reizend. Nur haben sie mit dem CrossCore-Studio von ADI auch so ihre Schwierigkeiten und andere DSPs haben wir hier nicht. An einen FPGA habe ich auch schon gedacht (damit habe ich in meiner Bachelorarbeit gearbeitet). Aber zum einen finde ich, dass das ein bischen mit Kanonen auf Spatzen geschossen ist, da ich wirklich zu 95% MAC-Befehle ausführen muss und zum Anderen denke ich, dass ich nochmal Platinen layouten muüsste, um die passenden Audio Schnittstellen an den FPGA zu bekommen. Aber stimmt schon: Auf einem FPGA ließe sich mein Projekt auch ganz vorzüglich umsetzen. Naja, im Moment überlegen wir, ein ADZS-SC584-EZLITE zu besorgen: http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/EVAL-ADSP-SC584.html#eb-overview Das hört sich von den technischen Daten her super an und ist mit 435$ auch nicht so mega teuer. Aber leider wäre ich dann nach wie vor Auf CrossCore Studio angewiesen.
So, das Problem hat sich erledigt. Ich habe mir ein FPGA-Board (ARTY S7 von DIGILENT) besorgt. Es hat nicht ganz meine Wunschleistung, aber es war recht günstig. Ich hätte es auch bezahlt bekommen, aber dann hätte ich noch drauf warten müssen und so habe ich es gestern bestellt und heute war es da. Und was soll ich sagen? Ich bin begeistert!!! Nach wenigen Stunden bin ich mit dem Spartan 7 und Vivado weiter, als mit dem ADSP und CCES nach Wochen! Ich hab' echt schon gedacht, ich wäre blöd, weil ich einfach nicht brauchbar auf den ADSP drauf kam. Die Dokumentation zum Spartan ist OK und Vivado sehr viel intuitiver, als ich das von der ISE in Erinnerung hatte. Jetzt wird es also mit dem FPGA weitergehen. Unschön ist natürlich, dass ich erstens so viel Zeit mit dem DSP verloren habe und es zweitens in der Arbeit nicht so schön begründen kann, warum ich jetzt doch den FPGA verwende... Und es wird nun einige Fleißarbeit auf mich zukommen: Alle Interfaces müssen entworfen oder die IP-Cores eingebunden werden (vor dem DDR3-Controller habe ich am meisten Schiss) und die Algorithmen muss ich natürlich parallelisieren...
So. Die Abschlussarbeit ist fertig. Es ist richtig cool gewesen ... eine echt geile Zeit, auch, wenns bei mir zum Schluss etwas drunter und drüber ging (aber eher privat). Leider habe ich das System nicht vollständig aufbauen können. Das Hauptproblem war die Anbindung des DDR-3-Speichers. Der Memory Interface Generator in VIVADO hat nicht richtig funktioniert und per Hand in VHDL einen Controller zu schreiben ist auch nicht so einfach... Aber ansonsten ist es echt krank, was man mit so einem kleinen FPGA schon machen kann. Wieso nutzt man überhaupt noch DSPs? Wieso wollte ich anfangs einen DSP nutzen??? Naja, wie auch immer. Wer eine kleine Anleitung zum Arty-S7 für Audiosignalverarbeitung, oder ein I²S-Interface IP-Core gebrauchen kann, oder Näheres zu meiner Arbeit erfahren möchte, kann mir gerne ein PM schreiben. Ich muss mir jetzt erstmal einen Job suchen... wahrscheinlich werde ich wieder in meinem alten Beruf zurückkehren --schade eigentlich--. Hardwarenahe Entwicklung und Signalverarbeitung haben mir viel viel Spaß gemacht, aber es wird wohl bei diesem kleinen Ausflug bleiben. Habt eine gute Zeit!! Michel
Warum publizierst Du die Anleitung nicht einfach? Das Arty ist ein gängiges board.
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.