Datum:
Hallo, ich habe mal wieder eine neue Version meines Audio-Projekts hochgeladen. Zu finden unter : http://www.mikrocontroller.net/articles/Audio-Projekt Jeder der ein Spartan 3 Board hat und 1 oder 2 Audio-Codecs daran ageschlossen bekommt kann den Audio-Prozessor nun benutzen. Der DAP kann per RS232 (vom PC aus) oder per SPI (vom uC aus) gesteuert werden. Es können damit Mischpulte (ok 4 Mono-Eingänge ist nicht der Hit, aber es ist ja noch ausbaufähig), Delays (später auch Chorus, Flanger), Equalizer und Synthesizer mit gebaut werden. Eine PC-Software zum steuern des DAPs existiert schon in einer Roh-Version und wird dem Audio-Projekt noch hinzugefügt. Weiterhin fehlt noch eine ausführliche Dokumentation des DAPs (Befehlssatz, Arbeitsweise, Beispiele). Aber alle diese Dinge werden im laufe der Zeit noch nachgereicht. Ich möchte nochmals Werbung dafür machen das ich noch Leute suche die Lust und Zeit haben an solch einem Projekt mitzuwirken, da ich denke das man aus dem Projekt noch eine ganze menge machen kann. Gruß Rene
Datum:
Ich hab mal probiert, das 6.2 Projekt mit ISE 9.1 zu implementieren. Wenn man alle ressourcensparenden Optionen wählt, kommt das P&R durch. Dafür alle Optimierungen auf Area stellen, die FSM-Codierungen auf sequential, LUT into BRAM usw. Dann müsste es auch bei dir klappen. Wenn ich neben der Arbeit noch Zeit finde, schaue ich auch mal in den Code rein.
Datum:
Du hast Dir ja eine Menge Arbeit gemacht. Aber um das zu nutzen, müsste MIDI ran! Geht das ?
Datum:
@ratze MIDI wäre dann die Aufgabe des uCs (der DAP ist ja auch per SPI steuerbar). Da ich aber erstmal eine einfache Testschnittstelle haben möchte (bis ich weiß was noch zu tun ist) ist RS232 vorgesehen. Wenn ich die Doku fertig habe (kann noch was dauern) sollte es für jeden sehr einfach sein selbst MIDI zu implementieren (egal ob über MIDI-Buchsen, oder mal als anregung : Igor- oder obdev.at-USB für AVR, welches als MIDI-Device fungiert, wär das was ?! :-)) Zu der Doku kommen dann noch ein paar Beispiele wie man Töne erzeugt und Filterkoeffizienten berechnet, nebst Delphi Programm zum groben Testen. Interesse ? Gruß Rene
Datum:
Darf ich mal fragen, welchen Codec du verwendet hast? Ich konnte da keine Info zu finden.
Datum:
@tom den TLV320AIC23B von Texas Instruments. Steht in der Übersicht :-) (ok, ist da etwas blöd platziert, werds noch in den Schaltplan packen)
Datum:
den codec ?! na ja .. eher low-cost. aber für halbwegs gescheite tests ausreichend und (was mir wichtig war/ist) single supply und wenig beschaltung :-)) (soll ja noch hobby sein)
Datum:
Ja und vor allem der int. Verstärker. Nicht das das ein Problem wäre, ist aber sehr angenehm. Wo hast du das Teil gekauft?
Datum:
hab ich als sample bei ti bekommen. kannst glaube ich 3 stück auf einmal ordern.
Datum:
@t.m. hab mal etwas mit den optionen gespielt, aber der p&r kommt bei mir nicht durch. welche optionen genau (ich hab mit dem optimierer noch nicht so viel gemacht, von daher weiß ich nicht welche optionen speziell für area gelten, bzw. welche optionen sich auf die area auswirken) hast du eingestellt ? kannst du mir evtl. screenshots von den optionsdialogen machen ? gruß rene
dank schonmal im voraus. hier mal ein screenshot der optionen bei denen am wenigsten ungeroutete signale nach dem par herauskommen. gruß rene
Datum:
Hallo, Respekt erstmal, ich haette nicht gedacht das es realisiert wird. Ich benoetige für ein Design vielleicht die I2S Schnittstelle, weiss jemand ca. wieviele Makros benoetigt werden, desweiteren ist es moeglich die I2S Schnittstelle in ein CPLD zuquetschen oder werden DCM's benutzt? Gruß, Dirk
Datum:
@dirk dcm's werden keine benutzt. den i2s teil kannst du gerne verwenden. musst wohl dran denken das dieser nur als slave arbeitet (seine clocks also von außen bezieht). du müsstest den i2s teil aber anpassen da dieser für 2 i2s signale ausgelegt ist (also 2 stereo ein und ausgänge, ergo 4 mono ein und ausgänge). bei 1 i2s signal (also 1 stereo ein und ausgang) müsste es in einen cpld pressbar sein. anzahl der flipflops für 1 i2s (grob übern daumen gepeilt) 2 2 24 = 96 flipflops fürs senden und empfangen, dann noch ca 6-7 flipflops für die zähler, 6-8 fürs einsynchen und noch 2-3 für die statemachine, plus ein paar ff's an die ich bestimmt nicht gedacht habe :-). in einen 95144 könnte (müsste) es also passen (wenn meine rechnung stimmt). ansonsten : ausprobieren :-) gruß rene
Datum:
Angehängte Dateien:So, im Anhang sind die ISE-Einstellungen als *.jpg zu finden. Damit hat er zwar auch ne Weile gebraucht, aber beim P&R kann alles geroutet werden.
Datum:
@t.m. vielen dank. jetzt lässt es sich synthetisieren. cool. mal schauen was sich noch zusätzlich in dem fpga unterbringen lässt :-)) aber es scheint ja schon so zu sein das das dingen bald am poller ist. gruß rene
Datum:
Jetzt gibt es ein kleines Demo-Programm welches den DAP zum 3-Band Stereo Equalizer macht (inkl. Audio-Demo). Weitere Demos und Programme folgen ...
Datum:
update : habe 3 weitere Demos hochgeladen und altes eq-demo upgedatet (war kein stereo sondern ein mono-eq :-x) jetzt gibt es ein Stereo Equalizer Demo, ein Synthesizer-Filter Demo, ein Mixer-Demo und ein Delay (Chorus)-Demo. Hoffe auf nachbau und Feedback Gruß Rene
Datum:
update : - codecs werden nun vom pc aus initialisiert (mit den demo-programmen). allerdings funktioniert das nur mit der 6.2'er version (ise 9.1 hat es trotz optimierung nicht geschafft das teil zu routen) - habe neue audio-demos (mp3) hochgeladen. als audio-quelle dient ein werkspreset meiner roland mc505-groovebox. ich würde mich über ein feedback freuen (egal ob demos/code-überflug/nachbau/artikel-statement). gruß rene
Datum:
hat denn mal jemand das ganze mal getestet ? würde mich echt freuen mal was feedback zu hören ....
Datum:
Also ich hab mir mal die demos angehört: also wenn das wirlich über deinen FPGA lief, dann kann der schon allerhand, und die qualität ist dafür das dir die wandler atm egal sind auch ganz gut! wäre denn mit dem teil auch ein 16band EQ oderso möglich?
Datum:
also 16 band eq mit 2 mono-kanälen ist möglich (habe ich zwar noch nicht getestet aber rein rechnerisch kann ich 40 eq-filter insgesamt rechnen)
Datum:
Ich kenne das Projekt nicht, sitze aber des öfteren über einer Resourcenplanung und würde dazu raten, Elementarzellen zu definieren, die man iterative pipelinen kann. Dann werden Divider und solche Prozesse sinnvoll ausgenutzt. Hier würde ich als eine Elementarzelle ein solches Bandelement sehen. Dann kommt man zwar auf eine höhere additive Latenz, aber das ist im Idealfall nur 1 Clock.
Datum:
@axel danke für den tip also divider werden nicht genutzt, nur multiplizierer und addierer. wie würde man denn am besten eine solche mac-einheit (multiply and accumulate) in elementarzellen zerlegen ? ich habe mir auch schon überlegt einen core-generator einzusetzen, wollte das aber bisher nicht machen da ich zum einen gerne den code nach möglichkeit 1:1 (bis auf die blockrams) auf einem altera ausprobieren möchte und zum anderen wollte ich den mikrocode erstmal so belassen. vielleicht das ich in einer späteren version das mal mache, aber im moment wäre ohnehin nur ideenfindung für ein optimaleres design angebracht, da ich erstmal feedbeck mit dem bestehenden system sammeln möchte. daher hoffe ich das mal jemand das ganze nachbaut. gruß rene
Datum:
das wirds wohl sein :-) ok, gebs ja zu das die chance recht gering ist, das diese konstellation (fpga-interessierte, leute die ein spartan 3 board haben, leute die an audio interessiert sind, leute die sich den codec ans board anflanschen) erfüllt ist ... aber die hoffnung stirbt ja zuletzt :-)
Datum:
[x] Spartan3-Board [x] an Audio interessiert [ ] Zeit, um sich die Peripherie zu basteln :-( Aber vielleicht tut sich im letzten Punkt ja demnächst was, da steht dein Projekt ganz oben auf der Liste :-)
Datum:
was ist eigentlich der unterschied zwischen spartan 3 und virtex 4 und 5 außer das der 5er in 65nm gefertigt ist?
Datum:
also den genauen unterscheid zwischen spartan und virtex kenne ich nicht. ich meine das die struktur bei den virtexes etwas anders ist (interconnects und clbs). und manche virtexes haben einen (oder mehrere) powerpcs mit on-chip. bin mir aber nicht ganz sicher. gruß rene
Datum:
Update : Delphi-Quellcodes zum EQ-Demo, Filter-Demo und Delay-Demo hochgeladen.
Datum:
update : audio demo eines synthesizers mit dem dap hochgeladen. der dap wird vom pc aus gesteuert (hüllkurven, sequencer, filterkoeffizienten). ein pc-programm zum steuern (inkl. quellcode) folgt bald
Datum:
ich habe mich nochmals mit dem problem beschäftigt, das sich das design nicht vernünftig mit ise9.1 synthetisieren lässt (unter 6.2 habe ich gar keine probleme, da geht das ganze sogar richtig fix). ich bin langsam am ende mit meinem (kleinen) latein. egal wie ich es anstelle : es gibt immer probleme beim routen (selbst wenn ich einen spartan3 400'er nehme, muß ich die optimierung einschalten, damit es überhaupt geroutet werden kann). die "ursache" liegt wohl in der MAC-Einheit. da ich "einfach" nur 2 32 bit signed zahlen multipliziere (den * operator) denke ich liegt da der hund begraben (kein pipelining->große multiplizierer und addierer->viel interconnect-routing->problem). nun denke ich das man den multiplizierer in pipelining machen müsste um das problem zu umgehen. (jedenfalls würde mir hier nichts anderes einfallen) wie würde man eine solche operation (32x32 bit multiplizieren und akkumulieren) am besten in ein pipelining schema pressen (nach möglichkeit ohne irgendwelche core-generatoren zu benutzen da ich den dap erstmal weitestgehend platform-unabhängig [abgesehen von den blockrams] beschreiben möchte) ? wie würde man sowas am einfachsten in vhdl implementieren ? hoffe das mir da jemand helfen kann. der quellcode zu dem "problem" ist im audio-projekt verfügbar. die datei in der die mac-einheit steht ist "sdsp_core_mc.vhdl". (vielleicht findet ja doch jemand eine andere ursache für das problem) gruß rene
Datum:
TheMason wrote: > wie würde man eine solche operation (32x32 bit multiplizieren und > akkumulieren) am besten in ein pipelining schema pressen (nach > möglichkeit ohne irgendwelche core-generatoren zu benutzen da ich den > dap erstmal weitestgehend platform-unabhängig [abgesehen von den > blockrams] beschreiben möchte) ? Ein Algorithmus von http://opencores.org benutzt folgende Dekomposition:
X*Y = (XH<<16+XL)*(YH<<16+YL) = XH<<16*YH<<16 + XL*YH<<16 + XH<<16*YL + XL*YH |
Das ergibt 4 Multiplikationen mit der Hälfte der Bitbreite. Einmal weiter, und du bist bei 16 Multiplikationen mit 8 Bit. -- stefan
Datum:
hallo stefan, das man eine 32x32 multiplikation in 4 16x16 aufteilen kann ist mir klar. mir geht es nur darum wie man sowas am besten so in vhdl implementiert das sich eine optimale pipeline-struktur ergibt, damit das design ohne probleme in den fpga passt (egal ob mit 6.2'er ise oder 9.1'er), wenn das implementierungs problem von 9.1 denn wirklich an der mac einheit (speziell dem multiplizierer ) liegt. und da ich nicht sooo fit in vhdl bin würde mich mal interessieren ob dem wirklich so ist, oder ob es an einer anderen stelle probleme gibt (wäre mir ehrlich gesagt lieber, dann muß ich nämlich nicht zwangsweise den ganzen micro-code umschreiben/neuschreiben/simluieren und und und ...) aber dazu müsste man sich tiefer mit meinem quellcode auseinandersetzen, und das ist für die erfahrenen hier im forum denke ich ein zeitproblem ... :-( trotzdem danke für die anregung. gruß rene
Datum:
Stefan und Hans, ich denke, daß nach der Synthes DASSELBE rauskommt, auch wenn man es häppchenweise vorformuliert. Um diese Struktur zu erzeugen und zu nutzen, müsste man schon ausdrücklich Register dazwsichen setzen. Dann hat man eine schnellere pipline.
Datum:
@fpga jolly danke für den hinweis. hoffe nur das es vielleicht irgendwie ohne pipeline geht, damit ich den mikrocode nicht ändern muß (dauert inkl. simulation so lange ...) @all wäre schön wenn jemand mal über den code (speziell den sdsp_core_mc.vhdl) gucken könnte und mir sagen könnte ob da vielleicht eine formulierung drin ist die die probleme verursacht. möchte echt nur ungern den multiplizierer durch ne pipeline ersetzen müssen. gruß rene
Datum:
muß jetzt mal meckern .... gibt es denn überhaupt niemanden der ein bischen feedback gibt ? was sagt ihr zu den audio-demos ? (ich trau mich ja schon gar nicht zu fragen ob mal jemand auf das design geguckt hat, oder geschweige denn das es mal jemand ausprobiert hat, oder nachge baut hat) ich weiß ja das schönes wetter und wenig zeit da ist, aber es ist echt ätzend wenn kaum ein schwein was dazu sagt ... (ich weiß ja noch nicht mal wer lust hat sowas nachzubauen bzw. daran mitzuwirken) menno nu sach doch mal einer watt ... ist echt frustrierend wenn man macht und tut und keiner was dazu sagt ... so genug gemeckert gruß rene
Datum:
Hi Rene! Nach diesem (emotionalen) Aufruf schreibe ich dir mal ein Feedback. Also ich bin stark beeindruckt von dem Projekt. Ich weiß nur nicht, wie viel dir so ein Statement Wert ist von jemanden, der in der FPGA Welt erst ganz am Anfang steht. . . Ich habe mir mal die Demos angehört, und finde den Klang schon sehr gut. Aber noch mehr beeindruckt mich das Wissen und das Durchhaltevermögen, das hinter deinem Projekt steckt. Grudsätzlich habe ich schon interesse daran, an so einem Projekt, wie deinem, mitzuwirken. Leider habe ich kein eigenes FPGA Board, und in der Firma, wo ich gerade bin haben wir nur Altera FPGAs. Außerdem schreibe ich gerade meine Diplomarbeit, und deswegen keine Zeit. . . Da ich aber Hobbymusiker bin, kann es durchaus sein, dass ich in naher Zukunft anfange mich mit ähnlichen Dingen zu beschäftigen. Dann werde ich vielleicht auf dich und dein Projekt zurückkommen, da es mich wie gesagt schwer beeindruckt und das Thema auch interessiert. Gruß Maik
Datum:
hallo maik, erstmal danke fürs feedback. musste einfach nur mal eben meckern. ist einfach nur was doof wenn so gut wie gar kein feedback kommt. und wert ist mir eigentlich jedes feedback (außer von einem troll :-))). ich seh mich im übrigen auch als anfänger (mache seit 2 jahren hobbymässig vhdl, kann mich also mit einem berufsmäßigen professional nicht messen, ist aber auch nicht mein anliegen). das wissen zum synthesizer/audio-basteln selbst habe ich am pc erworben. die umsetzung in vhdl war nur eine idee, die erstaunlich schnell funktionierte, da ich schon vor knapp 1 1/2 schonmal einen versuch mit einem audio-prozessor gemacht habe der gründlichst daneben ging, habe da aber eine menge gelernt. ich freue mich immer zu hören wenn jemand vorhat das nachzubauen, und wenn wenig zeit da ist ist ja auch kein thema (bei dem schönen wetter ists ja auch nur verständlich). hoffe aber trotzdem mal ab und zu was zu hören, und das sich noch ein paar mehr leute an dem projekt beteilgen, zumal ich das ganze auch gerne mal auf nem altera laufen sehen würde, selbst aber kein altera board habe. ansonsten, wenn du mal zeit und lust, ein board, und ein paar funktionierende codecs hast kannst du ja gerne mal was testen. gruß rene
Autor:
Andreas Schwarz
(andreas)
(Admin)
Datum:
Hallo, ich verfolge das Projekt interessiert. Ich habe noch keine Hardware um es live zu testen, aber ich versuche gerade ausschnittsweise mit GHDL zu testen. Da gibt es allerdings ein Problem: du verwendest STD_LOGIC_ARITH und STD_LOGIC_UNSIGNED, was nicht standardisiert ist und von GHDL nicht unterstützt wird. Hättest du was dagegen, wenn ich das auf NUMERIC_STD umstelle und im SVN committe? Gruß Andreas
Datum:
@Andreas: Zur Not kennt ghdl auch --ieee=synopsys. Aber den Code umstellen wäre der saubere Weg. Rick
Datum:
hallo andreas, mit dem umstellung ist kein thema, solange es sich noch mit ise noch synthetisieren lässt :-). sonst sag mir einfach wenn du es eingecheckt hast, dann teste ich das mal. bin leider nicht von selbst auf die idee gekommen das man vielleicht besser einheitlich unsigned/signed statt den misch-masch mit std-logic/signed verwenden sollte. :-/ muß auch noch die delphi sourcen einchecken, möchte aber erst das synthesizer -demo fertig machen. gruß rene
Datum:
Wie wäre es mal mit einem Mono-Stereoprozessor? Man nutzt den linken Kanal als Monoeingang, bzw. mischt bedarfsweise den rechten dazu. (Das macht aber nur Sinn, bei reinen gepannten Signalen, also Pegelstereofonie). Gfs müssen die Bässe weggeschnitten werden. Von diesem Monosignal ausgehend erzeugt man ein Phasenverschobenes Signal über Delay: optimal sind 20ms - 30ms -> bei 48kHz wären das dann etwa 1kB. Diese Signal wird in der Größenordnung von etwa 25% bis maximal 50% dem Original hinzugemsicht und zwar dem einen Kanal positiv, dem anderen negativ.
Datum:
@jürgen also die einzelnen Komponenten (Filter und Delay) funktionieren ja schon. Sollte machbar sein :-)
Datum:
Wenn ich das richtig sehe, funktioniert das Ganze mit einer Art Befehlsprozessor ?
Datum:
@techniker richtig. die befehle im PMEM (programmspeicher) werden dekodiert und an den sdsp bzw. util core weitergegeben und dort ausgeführt. jeder dieser kerne hat einen eigenen micro-code speicher in welchem jeweils 16 mögliche befehle drinstehen. somit hat der dap 32 befehle (16 befehle pro kern, 2 kerne). was bzw wie man die befehle anordnet bleibt einem selbst überlassen. und da man noch einfluß auf den micro-code speicher hat kann man sich (im rahmen der möglichkeiten der beiden kerne) seine eigenen opcodes bauen (oder bestehende optimieren). @all hat jemand schonmal den audio-prozessor aufgebaut ? kann mir dazu jemand mal feedback geben ? gruß rene
Datum:
Das FPGA ist also eine Art Coprozessor - verstehe. Was ist denn noch alles an Modulen geplant?
Datum:
im moment sind folgende sachen geplant : - wavetable/sampling modul / opcodes (um samples als audio-quelle nutzen zu können) - ide-interface für harddiskrecording bzw. wiedergabe von audio-dateien - interface zum einschleusen/auslesen von audio-daten via uC (z.b. arm7 oder so) - opcodes für dynamik-einheit (ist allerdings etwas aufwendiger)
Datum:
Die IDE Schnittstelle würde mich interessieren. Allerdings brauche ich vorwiegend ein Digitalnterface und weniger einen 0815 Audio Codec. Noch etwas zu dem Prozessor (und meinem Vorschlag des MS Wandlers): Ich würde es bevorzugen, wenn das direkt in hardware gelöst waere.
Datum:
@jürgen also das harddiskrecording ist erstmal nur als grobe idee angedacht. ich habe zwar schon eine idee wie man das am besten umsetzen kann, allerdings werde ich dazu wohl auch noch einen steuerprozessor (msp430/arm7) einsetzen der dann noch andere sachen machen kann. das ide-interface als solches werde ich wohl per statemachines realisieren. und dann wahrscheinlich auch nur im pio-mode (der einfachheit halber). was verstehst du unter digital-interface (i2s/spdif/tdm/adat ?!) prinzipiell kannst du da alles anschließen was i2s unterstützt, solange du in dem ganzen system einen master (und wenn es benötigt wird mehrere slaves) der den dap versorgt (da dieser auch nur als slave arbeitet) >Noch etwas zu dem Prozessor (und meinem Vorschlag des MS Wandlers): Ich >würde es bevorzugen, wenn das direkt in hardware gelöst waere. was meinst du damit, direkt in hardware gelöst ? als fester algorithmus der "direkt" anläuft oder eine schaltung die nichts anderes machen kann ? prinzipiell kann man das mit dem dap auch machen. man muß nur das programm mit dem der dap hochfährt ändern (beim booten des fpgas wird auch direkt ein programm für den dap geladen). gruß rene
Datum:
Ok, das durchschaue ich jetzt nicht so genau, aber es klang so, als ob der DAP einzelne Befehle abarbeitet. Damit den Stereoprozessor zu realsieren (oder andere Effekte) wäre umständlich, platz und Zeitfressend, bzw es würde eine ordentliche Latenz produzieren. Ich mache solche Sachen derzeit mit einer "programmierbaren" Soundkarte, die einen 56301 benutzt. Dort man das einstellen. Ich will aber hin zu einer hardware-Lösung mit fester Codierung, da gerade solche "low-level" Aktionen praktisch ohne großen Flächenbedarf im FPGA laufen - abgesehen vom Delay-RAM. Zum DIGI : Ich benötige zunächst SPDIF - ADATA optical wäre aber dernächste Schritt. Was vor allem passieren muss, ist ein flexibles Sampling und Resampling auf "analoger " Ebene mit externer Synchronisation. Damit bekommt man zwar 2 worte Latenz - aber einen Datenstrom OHNE zusätzliche jitter-Artefakte. Ich habe bisher noch kein System am Markt gefunden, das das kann!
Autor:
Andreas Schwarz
(andreas)
(Admin)
Datum:
Wieso würde das Latenz erzeugen? Die paar Befehle sind doch in ein paar Takten abgearbeitet.
Datum:
Du brauchst ja auch noch Verwaltung, um die Befehle abzuarbeiten und ausserdem sehe ich einen deutlichen Mehraufwand darin, eine allgemeine Hardware per Befehle dazu zu bringen, diese Grundfunktion zu realisieren. Mal abschätzt sähe das so aus: RAMWR++; RAM(RAMWR) = INPUT RAMRD = RAMCNT + 960; M = RAM(RAMRD) L = M - INPUT * k; R = M + INPUT * k; Macht schonmal 5 sequenzielle Befehle. GEschätzt 10 CLK-Zyklen Der nächste Punkt: Auch ein "paar Befehle" sind immer Latenz. Bei fest verdrahteter Hardware kann ich die genau berechnen und bei der Verarbeitung anderer Datenströme mit berücksichtigen. Die Funktion dieses hardware-Prozessors wird damit für mich auch nutzlos, da ich mit meiner €85,- Soundkarte (gebr Soundscape Mixtreme) schon jetzt schneller bin!
Datum:
@jürgen ich geh mal (kurz) darauf ein : es wird pro sample (also alle 20us @ 44khz) das komplette programm sequentiell (!) abgearbeitet. da der fpga mit 50mhz läuft hat man bei 44khz etwa 1000 takte. in diesen werden die befehle geholt, dekodiert und ausgeführt. rein theroretisch hast du somit eine latenz von nur 1 sample (plus noch 2 samples für den transfer vom/zum wandler) die latenz die man vom pc her kennt kommt nur dadurch zustande das der pc keine so schnelle reaktion auf ein sample zeigen kann. da werden mehrere samples zwischengepuffert (das ergibt dann die latenz) und zeitversetzt abgearbeitet. der dap hat also eine geringe latenz. gruß rene
Datum:
Ach ja, noch eins : Ich benutze das DELAY RAM auch als Echo-RAM für die Kurzreflexionen und den Hall. Der Faktor k wird so eingesetzt, das er das DECAY kompensiert. Damit kriege ich in der Addition oben auch diese Infos mit rein. Erzeugt werden die KR jeweils mit Zählern, die ein Delay beinhalten und voll parallel laufen. Der eigentliche Schritt, nämlich die Synthese des L-R-Signals läuft damit in einem einzigen CLOCK! Der Rest an vorbereitender Rechnerei ist voll parallel, wobei die Stereofunktion nur aus einem einzigen RAM-Write besteht, der aus einem Addierer (mit den geloopten REFs) besteht. Wenn ich mit statischen Refelxionen arbeiten würde, benötigte ich gerade mal 1 Clock, 3 24Bit-Multiplier und 4 Addiere, sowie die Zählschleife. Die Stereofunktin mit fester Verstärkung (50%Mix) braucht gerade mal 2 Addierer! Baue das mal in Software nach.
Datum:
@Mason: Man hat also (wie üblich bei DSPS) für alle Prozesse, die man programmiert zusammen ein Sample Zeit. Das ist sowoeit klar. >2 samples für den transfer vom/zum wandler) Das ist unvermeidbar ? >die latenz die man vom pc her kennt kommt nur dadurch zustande das der pc keine so schnelle reaktion auf ein sample zeigen kann Das ist auch klar. Die o.a. Karte arbeitet aber nicht über Software, sondern kriegt von der Controllsoftware lediglich die Config. Die Funktion arbeitet unten in hardware. Soweit ich das sehe auch innerhalb eines samples.
Datum:
@jürgen nur mal eben am rande : mir geht es nicht darum gegen einen 56xxx oder sharc oder blackfin "anstinken" zu wollen, das ist hoffentlich klar, oder ? mein ziel ist es vielmehr eine (einfache) plattform aufzubauen mit dem audio-signale (einigermaßen) flexibel bearbeitet werden können. falls damit auch noch hd-recording (da bin ich ja schon froh wenn ich überhaupt 4 mono kanäle schaffe) möglich ist, ists doch prima. ein synthesizer, einfache effektgeräte und ein kleines mischpult funktionieren ja schon. das man einige operationen (z.b. deinen ms-wandler) mit einem fpga sicherlich sehr elegant lösen kann ist klar, aber dann hättest du nur eben diese eine funktion. wenn du das als einzelnen opcode in meinem dap haben möchtest muß man auf micro-code ebene herunter. und kannst dabei noch parametrieren (z.b. mischungsverhältnis, oder grenzfrequenz um die bässe nur in die mitte zu legen, oder oder oder ...) >2 samples für den transfer vom/zum wandler) >Das ist unvermeidbar ? bei dem design das ich verwende ist es unvermeidbar (brauche immer noch ein daten register neben dem schiebe-register), aber ich wüsste nicht warum das schlimm sein sollte, immerhin sind 3 samples (2 für i/o, 1 für die verarbeitung) gerade mal 60us. eine soundkarte hat deutlich mehr, und eine creamware-karte wollte ich ja auch nicht aufbauen :-)
Datum:
hat eigentlich jemand mittlerweile den DAP auf dem nexys board mal ausprobiert und kann mir feedback geben ?
Datum:
ist das projekt so unattraktiv ? fehlen soviele informationen ? sagt doch mal was ...
Datum:
Hallo Mason, super Projekt ! Wollte mir das immer mal aufspielen, mir fehlt leider nur die Zeit :) hab das Nexys und auch die Codecs. Hab es aber noch nicht geschafft, Leiterplatten für die Codecs zu ätzen... Freue mich aber riesig, das demnächst mal auszuprobieren... ! Ist also auf gar keinen Fall unatraktiv !!! gruß Thomas
Datum:
So, ich hab mir jetzt mal den Audio Codec nachgebaut, hat aber leider nicht funktioniert. Ist es richtig, das der Mode Eingang auf GND liegt ? Das wäre ja nach Datanblatt Two Wire... kann man irgendwie nachvollziehen, ob der Codec richtig initialisiert wurde ? Der Quarz ist 12 MHz, richtig ? Hab die Platine noch mal neu geroutet, damit ich eine einseitige Platine habe... muss das noch mal durchgehen, hatte keine Lust mehr :) Gruß Thomas
Datum:
@thomas ich hab im schaltplan an den wichtigsten pins zum connector überall doppelt und dreifach widerstände vorgesehen. zum einen um gegen kurzschlüsse zu schützen, und zum anderen damit man durch weglassen sich den codec "vorkonfigurieren" kann. z.b. kann man indem man entweder r5 oder r18 weglässt das dingen als spi oder twi konfigurieren. mit r19 bzw. r23 wird bestimmt ob der codec mit dem quarz laufen soll oder seinen clk über pin 1 des connectors bekommt. die initialisierung mache ich meist so : - codec resetten (register 15) - device als master - clk divider setzen - audio routing setzen (zum testen das bypass-bit setzen) - den rest (power off/lautstärken/usw). dann schaue ich nach ob der quarz schwingt und ob BCLK und LRCLK anliegen und ob an DOUT etwas zappelt. wenn dem so ist funktioniert der codec. einen 12mhz quarz kann man ebenfalls verwenden, muß dann aber das clk-divider register richtig setzen. also der codec ist von der beschaltung her recht einfach und auch die initialisierung ist super-simpel. ich hatte bisher eigentlich nie große probleme damit. vielleicht konnte dir meine kleine anleitung etwas helfen. wenn du noch fragen hast, frag ... gruß rene
Autor:
Rene B.
(themason)
Datum:
Mal ein kleines Zwischenupdate. Im Audio-Projekt-Artikel habe ich vor einiger Zeit ein paar Bilder eines Aufbaus des DAP's hochgeladen. Der DAP läuft in einem FPGA Board welches von Thomas Pototschnig designt worden ist (miniGA). Das Bild ist unter "DAP mit selbstgelötetem FPGA Board" zu finden. Gesteuert wird der DAP von einem AVR (im moment mega32, wird demnächst aber ein mega644). Das Bild dazu ist in der Picture-Gallery :-) Das ganze funghiert als Synthesizer, bzw. soll ein solcher werden, bzw. ist dabei einer zu werden (und wie ich finde ein recht guter :-)). Kurzer Umriss : - 3 Oszillatoren - 2 Filter (seriell/parallel) - 2 LFO's - 2 Hüllkurven - Einspeisung eines externen Audio-Signals (wird zu den Oszis gemischt) - Modulationsmöglichkeiten (imm aufbau) - Delay (im aufbau) - Chorus (im aufbau) - EQ (im aufbau) Das ganze ist schon per MIDI steuerbar (allerdings funktioniert der SW UART noch nicht richtig, mit dem ich alle Parameter von außen steuern möchte, also kann ich momentan nur einige wenige Parameter per MIDI-Controller steuern). Zum Einstellen aller Parameter habe ich ein UI-Board gebaut welches einige Potis (16), Schalter (11) und LEDs (24) sowie ein Display und einen Drehgeber enthält. Leider habe ich beide Platinen noch nicht erfolgreich miteinander reden lassen können. Kommt aber noch. Was noch zu umzusetzen ist, ist ein Delay, Chorus und EQ als Effektsektion, dann ist der Synth von der Funktionalität (und von meinem persönlich gesteckten Ziel) her komplett. Wenn ich am Wochenende Zeit finde mache ich mal ein Audio und evtl. Video Demo des Synths. Sobald das Teil fertig ist (es fehlt wie gesagt nur noch die Kommunikation zwischen beiden Platinen, die SW ist größtenteils fertig) werde ich das gesamte Projekt (Schaltpläne, Sourcen, Bilder, Audiodemos, usw.) mit in das Repository aufnehmen, auf das das jemand nachbauen möge (sofern Zeit vorhanden :-)) Gruß Rene
Datum:
Hallo Rene, ich finde das Projekt sehr interessant. Für mich stellt sich die Frage, ohne das Projekt im Detail zu kennen, ob Du nicht auf dem Spartan 3 einen Softcore einsetzen möchtest, z.B. soc-lm32, siehe hier: https://roulette.das-labor.org/bzrtrac/wiki/soc-lm32 um den externen Mikrocontroller einzusparen. Gruß Dirk
Datum:
Hallo Dirk, kann man sicherlich machen. Dazu muß das derzeitige Design aber komplett überarbeitet werden, da durch die verwendung des 32x32 bit multiplizierers so wie er implementiert ist sehr viele ressourcen (speziell interconnects) verbraten werden die erweiterungen sehr erschweren. (bin ja schon heilfroh das ich das design überhaupt in einen spartan3 200 geprügelt bekommen habe, und selbst in einem 400'er wirds eng). allerdings benötigt die softcore cpu dann noch einiges an speicher, da man um floating-point rechnereien für die filterkoeffizienten nur schwer drum herum kommt. daher braucht der steuernde uC einiges an speicher (schließlich soll der ja nicht nur die koeffizienten berechnen, sondern auch alle anderen elemente bedienen wie lfo's, hüllkurven, modulation, midi usw ...) gruß und danke für den link rene
Autor:
Rene B.
(themason)
Datum:
hat denn mal jemand reingehört ? also so ganz ohne kommentar ist ja für die tonne .... *mecker
Datum:
Hey, Du stehst mit Deinem Projekt bei mir in der Warteschlange :-) Ich brauche nur noch Zeit und wahrscheinlich einen geeigneten AD-Wandler. Rick
Datum:
ich wollte eigentlich auch nur ein feedback zu den synthesizer-audio demos. daher das gemecker. ich denke 3 minuten demo-hören und 2 min ein kommentar posten ist doch nicht zuviel verlangt. es richtet sich ja auch nicht gegen diejenigen die das projekt nachbauen wollen. ich weiß das es (wegen der bauteile) nicht ganz einfach ist. wäre aber trotzdem schön mal ab und zu was von den leuten zu hören :-) also ein ganz artiges danke an rick. gruß rene
Datum:
@TheMason : Ich übersehe das Systen noch nicht so ganz, bringt das was, jetzt einen eigenen Befehlsinterpreter für Audiobefehlr zu schreibr? Wäre es nicht effektiver, das in C zu machen und einen Softcore zu nutzen? >im moment sind folgende sachen geplant : >- wavetable/sampling modul / opcodes (um samples als audio-quelle nutzen >zu können) Ist das schon drin? MIDI-Verarbeitung ist ja komplex! @Jürgen Schuhmacher : Machst Du damit Musikverarbeitung ? >Wie wäre es mal mit einem Mono-Stereoprozessor? Kannst du das bitte erklären, wie das gehen soll?
Datum:
@dr jones also ein softcore wäre sicherlich einfacher, aber ein microblaze (wäre am passendensten, da komplett 32bit) ist ja auch nicht kostenlos, und einen anderen uC mit komplettem environment (gcc usw) aufzusetzen ist (denke ich) auch nicht so einfach (jedenfalls denke ich das da schon noch einiges zu machen ist). außerdem gings mir für mich auch erstmal darum einen eigenen kleinen dsp (wenn man das dingen so nennen darf) zu entwerfen und mit diesem dann audio zu machen. zum thema midi : midi selbst läuft in dem steuerprozessor (in dem fall ein avr) ab. dieser übernimmt auch die berechnung der filterkoeffizienten und dergleichen. evtl. wäre/ist ein arm dafür sogar noch besser eeignet. thema weitere module : da im moment leider wenig resonanz zu dem gesamten projekt besteht, gehe ich da meinen eigenen weg, d.h. ich "reduziere" die funktionalität auf einen synthesizer, auf basis des fpga-boards von thomas pototschnig (ist ein echt kleines feines fpga-board). da ich aber generell das problem habe das das design der mac-einheit etwas "unglücklich" bzw "unvorteilhaft" ist, und ich leider keine zeit bzw. leute finde die mir dabei helfen können (mir würde eine serialisierte mac einheit schon vollkommen reichen) habe ich das problem das das design recht "klobig" ist, was sich erst mit größeren fpgas (so spartan 3-1000) in luft auflöst (mit der bestehenden mac einheit). von daher sind erweiterungen erst mit größeren fpgas möglich (ressourcenverschwendung) oder komplettüberarbeitung der mac-einheit und des microcodes möglich. aber wie gesagt müsste dazu mehr resonanz da sein. sonst ist das vertane zeit (da ich für mich alleine eher ergebnisse "sehen" möchte als ein "perfektes" design). ich hoffe zwar immer noch das sich leute für zusammenarbeit finden, aber das ist bei diesem projekt ein eher leidiges thema (sorry an die die interesse aber keine zeit dafür haben). dann würde sich auch eine umfangreichere doku lohnen, aber für mich alleine ist das gelinde gesagt "zeitverschwendung" bzw. blödsinn. mal schauen. ich überlege auch schon ob ich nicht einfach den audio-codec durch einen pwm ersetzen soll, damit vllt etwas mehr leute dieses projekt nachbauen können. so bräuchte man nur ein fpga board und einen avr und könnte was "hören", und das würde die sache evtl. attraktiver machen (wenn auch zu ungunsten des klangs). schaun mer mal ... würde mich trotzdem freuen wenn sich noch leute an diesem projekt beteiligen. für fragen steht dieser thread ja jederzeit offen. gruß rene
Datum:
Das Beste wäre sich er eine käuflich zu erwerbende PLattform. Ginge da nicht eines der zahlreichen Evalboards am Markt?
Datum:
das problem ist eher das ein audio-codec und ein steuerprozessor vorhanden sein müssen/sollten, da der fpga lediglich den audio-prozessor "beherbergt". wie gesagt kann man im vorhandenen design evtl. einen pwm output implementieren (zu lasten der klangqualität), aber ohne einen steuerprozessor gehts eben nicht (ausgenommen die steuerung per pc, aber das bringt nur die hälfte der möglichkeiten, bedingt durch die relativ langsame verbindung per rs232). und letzenendes scheitert es daran das zum einen ich leider kein solch erwerbbares board (mit wenigstens eins mit einem audio-codec) besitze, und zum anderen genügend andere leute genau dasselbe board besitzen. ansonsten dürften solch unterschiede (abgesehen von der intialisierung) marginal sein (bestenfalls im ucf file einige anpassungen). wie sieht es denn mit möglichen kandidaten aus ? (schau schon eine weile nicht mehr nach passenden plattformen, da es immer die frage ist : wieviele leute haben genau dieses board ...)
Datum:
Mit einem direkten FPGA-Ausgang sollte sich aber ein guter 1-Wandler bauen lassen, oder ? Bei 50MHz hätte man immerhin 1100 Stufen je 44kH also 10 Bit. Da man mit 15kHz filtern könnte, wären es schon 12 Bit. Brauchst halt nen guten Filter.
Datum:
@mrmister wie gesagt hatte ich das auch schon überlegt. aber dann hat man eben keinen eingang. und der würde bei dem system eben ein komplettes audio-system machen. so bin ich nur auf klangerzeugung festgelegt. mal schauen. hatte übrigens in der anfangszeit (als ich noch keinen codec hatte) mit einem 1-bit wandler gearbeitet (einfach nur ne pwm). einfach nur nen kondensator und widerstand dahin. zum testen hats gereicht.
Datum:
Ich habe mal die FPGA-Platine (mit Erlaubnis) von Thomas Pototschnig um einen Audio-Codec, einen AVR, eine bzw. zwei serielle Schnittstellen und ein MIDI Interface erweitert. Ich bin gerade dabei die Platine aufzubauen. Wenn alles klappt werde ich das Layout und eine Bestell-liste (evtl. kann man alle Spezialbauteile bei Sander Elektronik bekommen) hier hereinstellen plus dem Quellcode für den Synthesizer. Ich hoffe so das der Thread bzw. das Projekt wieder etwas zum leben kommt, da ich bisher halt nur für mich alleine daran rumgewerkelt habe, mangels Resonanz. An dieser Stelle nochmals der Aufruf an Leute die sowas gerne mal nachbauen wollen würden bzw an diesem Projekt mitwirken möchten. Ich suche immer noch Leute die bei diesem Projekt mitmachen möchten.
Datum:
>einfach nur nen kondensator und widerstand dahin. zum testen hats >gereicht. Wenn man mit 60MHz rausgeht und eine Grenzfrequenz von 20k nutzt, hat man immerhin 7 Oktaven an Headromm zur Dämfung. Klar, muss reichen.
Datum:
aber 7 oktaven bei einem filter erster ordnung (6dB/okt) macht dann auch nur 42 dB :-) also das signal sah auf dem scope schon echt mies aus, aber zum testen hats gereicht ... als ich dann den ersten codec drangeflascht hab hatte sich da thema klangqualität per pwm erstmal erledigt ;-)
Datum:
Interesse hätte ich auf jedem Fall am projekt bzw. an den Platinen, da ich mich mit FPGA schon lange auseinander setzten will. Tolle Idee
Datum:
>als ich dann den ersten codec drangeflascht hab hatte sich da thema >klangqualität per pwm erstmal erledigt ;-) Sag das mal den Audiophilen mit ihren 1-Bit Wandlern.
Datum:
>Sag das mal den Audiophilen mit ihren 1-Bit Wandlern.
na ja ... es geht bei dem projekt ja immerhin um einen dsp und weniger
den wandler. aber nen 8 bit pwm klingt sicherlich schlechter als nen
codec ;-)
und wenn man dreieck nicht von sinus unterscheiden kann (wie bei dem
8bit pwm) dann ist ein codec doch schon um klassen besser.
Datum:
versuch mal ein delta sigma DA Wandler statt einer PWM. Xilinx hat ein appnote dazu.
Soo ... es ist mal wieder Zeit den alten Thread hervorzukramen und meine Undercover-Works zu präsentieren .... Das komplette Projekt befindet sich auf einem (fast) komplett selbstgeroutetem Board und bietet : - Spartan 3 - 400 (TQFP144) - 1 MByte SRAM (15ns) - AVR ATMega644p mit 20MHz - Audio-Codec - MIDI-Schnittstelle - div. Stiftleisten Auf der Trägerplatine die das Audioboard beherbergt befinden sich neben den Anschlüssen für Audio, MIDI, RS232 und USB (nur für Stromversorgung) außerdem noch ein SPDIF Transmitter nebst optischem Transmitter, ein DataFlash und ein I2C EEProm. Auf einer Huckepack-Platine befindet sich ein 128x64 EA-DOG Display inkl. Touch-Panel und ein weiterer AVR (dieser übernimmt nur die Erfassung der Berührungen auf dem Touch-Panel sowie die Helligkeitseinstellung der Hintergrundbeleuchtung sowie 2 weiterer LED's [wobei der AVR später noch für andere Sachen gebraucht wird, allerings nur reine UI Aufgaben]) Die Software (bzw Hardware) des FPGAs übernimmt dabei folgendes : - Bearbeitung von Audio - Filtern, Mischen, Verstärken/Abschwächen - Erzeugen von Audio-Signalen - Verzögern von Audio-Signalen - RMS-Wert von Eingängen und Ausgängen - Speicherung (für Scope) - Ansteuern des Displays - Zyklisches wiederholen des Frame-Buffers - Grafik-Operationen wie Rechtecke oder Bitmaps kopieren Die Software des AVR's übernimmt folgende Aufgaben - Berechnen von Filterkoeffzienten (später werden diese aus dem DataFlash gelesen) - Framework für modulares System mit komplexen Blöcken (z.b. Equalizer, Chorus, Delay, Oszillator, ADSR-Hüllkurve, Envelope-Follower usw) - Steuerung der Module per MIDI - Steuerung der Module per Grafik (Touch-Panel) - Kommandointerpreter - GUI, basierend auf den Display-Funktionen des FPGAs Es ist noch nicht alles 100% fertig (speziell die Funktionen des DataFlashs müssen noch weiter getestet werden bzw. sind gerade im Umbau) aber prinzipiell (und auch in echt ;-)) funktioniert alles zufriedenstellend. Z.z. arbeite ich daran die vorher berechneten und im DataFlash abgelegten Koeffizientensätze durch die Filterkoeffizientenberechnung zu ersetzen, da das berechnen eines Filtersatzes (optimiert!!) ca 1.5ms dauert, und ich aufgrund von Speichermangel (der 644P ist zu ca 85% voll) einige Daten-Aufgaben ins DataFlash auslagern kann was dann ca 16KB freien Flash gibt (gäbs dochmal schon einen ATMega1284P zu kaufen seufz). Hier mal ein paar Fotos von dem Board ... Wenn ich die Software fertig habe werde ich das Projekt (sofern interesse besteht) hier reinstellen.
die hauptplatine auf der trägerplatine ...
drahtverhau par excellence ...
Datum:
und nochmal eine seitenansicht .... in kürze folgen audio und videos ... (wahrscheinlich auch auf youtube, weil 1MB große videos nicht viel hergeben :-) so. und nun hoffe ich das vllt noch ein paar leute interesse an diesem projekt bekommen :-)
öhm .. seitenansicht ...
Datum:
wäre noch schöner wenn leute interesse an diesem projekt hätten. dann würd sich auch eine veröffentlichung in einem weiteren artikel (ist ja auch nicht wenig arbeit) lohnen ...
Datum:
Glück Auf! Ich verfolge den Thread schon seit einiger Zeit. Mir fehlt es leider an der passenden Hardware sowie Kenntnissen zu DSP und FPGA, um hier aktiv mitzuwirken. Momentan arbeite ich an einer nicht weit entfernten Baustelle, einem 8in/8out MIDI-Interface mit AT91SAM7S. Hier hängt es noch an passenden UARTs für den SAM7... Ich könnte mir aber Vorstellen, dass man mit dem SAM ein MIDI/Audio-Interface gestaltet, welches dann den FPGA direkt ansteuert. Ein anderer Gedanke: Könnte man die I2S-Schnittstellen nicht auch direkt an eine PCI-Soundkarte anflanschen, wie z.b. SoundBlaster Live!/Audigy o.ä.? _.-=: MFG :=-._
Datum:
Wie sieht es denn mit der Verfügbarkeit von Platinen aus? Kann man die erwerben?
Datum:
@marcus mein (für mich) erklärtes ist es auch das ich an den fpga einen arm7 flansche. da der arm7 den ich anpeile (von atmel) auch die i2s schnittstelle beherrscht wäre es ein leichtes auf dem fpga ein 2.tes i2s interface zu implementieren das der arm7 auch als soundquelle dienen kann. mit der passenden hardware sollte es aber nicht so das thema sein. wenn sich genügend leute finden kann man für die platinen und die bauteile bestimmt eine sammelbestellung organisieren. bis auf die spezialbausteine (spannungsregler, platform-flash, speicher, codec, quarzoszillator, und den 74lvc07 die ganzen teile bekommt man am ehesten bei digikey oder wenn man z.b. bei csd nachfragt) sind alle bauteile bei reichelt beziehbar (inkl. display und touch panel). die platine kostet mich einzeln bei q-pcb ca 31 euro. zur not reicht es auch wenn man irgendwo ein spartan3 starterkit herbekommt und sich einen codec oder wahlweise a/d und d/a wandler organisiert. die restlichen bauteile sind dann ebenfalls einfach bei reichelt zu bekommen. >Ein anderer Gedanke: >Könnte man die I2S-Schnittstellen nicht auch direkt an eine >PCI-Soundkarte anflanschen, wie z.b. SoundBlaster Live!/Audigy o.ä.? ich weiß nicht ob man das auf dem foto gut erkennen kann, aber ich hab da noch einen optischen transmitter dran nebst cs8406 damit ich die audio-daten direkt digital ausgeben kann. denkbar wäre es sicherlich, aber ich wüsste nicht was das bringen sollte ... wenn man die soundkarte als sound-quelle nutzen möchte wäre spdif der universellere weg. solange man BCLK, LRCLK und entsprechend SDIN/SDOUT findet sollte das kein thema sein. aber man bräuchte dann eben immer einen pc.
Datum:
@gast ich habe selbst noch keine sammelbestellung oder dergleichen organisiert aber wie gesagt : wenn sich genügend leute finden, und jemand anderes die sammelbestellung der spezialbauteile macht kann man gerne darüber reden. ich hatte selbst mal bei sander angefragt ob man die bauteile über ihn beziehen kann, aber bisher noch nix gehört. vllt trigger ich da nochmal an. vorausgesetzt es finden sich genug leute dafür ... ich hab wie gesagt bei q-pcb für eine platine 31 € irgendwas bezahlt. müsste mal schauen wie teuer die platine bei 10/20 stück wird. eine andere möglichkeit wäre wenn man irgend einen bestücker findet der die dinger herstellt und man das ganze über einen der shops hier vertreibt. wäre der schönste, aber wohl auch aufwendigste weg denke ich. zumal sich das fpga board auch universell einsetzen lässt (man muß ja nicht den codec und die midi schnittstelle bestücken) ich denke dabei an das mini-la projekt hier. dadurch das auf dem board ein avr drauf ist wäre es sicherlich nicht uninteressant. aber wie gesagt bin ich ja schon die nächste version am planen. da kommt dann entweder ein xmega oder ein arm7 drauf. der arm7 hätte den vorteil das usb direkt mit drauf ist. aber die ganzen toolchains hab ich noch nicht am laufen (das war auch der [vorgeschobene] grund warum ich erstmal das ganze mit einem avr ans laufen gebracht hab). von daher muß das noch was warten.
Autor:
Rene B.
(themason)
Datum:
eig. hatte ich gehofft das jemand anderes den 100. post zu diesem thema macht, und ich nicht ein verzweifelungs-aufruf post machen muß. also : es gibt ein funktionierendes board, ich würde wenn sich genug leute finden lassen eine sammelbestellung versuchen auf die beine zu stellen. nun liegts an euch ob dieses projekt in der versenkung verschwindet oder nicht. das das projekt nicht ein 5-min wochenend projekt ist ist mir klar, aber es kann doch wohl auch nicht sein das es so wenig leute gibt die mit audio und uc/fpga zu tun haben oder ?!
Datum:
wau, sorry, eh tut mir echt leid, das ich nicht den 100. post gemacht habe, na ja, den projekt habe ich irgendwie irgendwann angesehen, aber leider aus irgendwelchen grund fast gleich vergessen. na, ich werde schon was bauen wollen, eine neue hardware muss es nicht gleich sein, habe schon zuviel FPGA boards, und wenns schon was neues, dann auch richtig, mit gross genug FPGA ok, aber versprochen, ich werde das projekt naher ansehen Antti
Datum:
wie versprochen: habe nach gesehen ein bishen: das Quellcode datei (.gz) 1) fur MCU Leute: kein code fur den MCU dabei :( 2) fur DSP Leute: keine DSP source code? :( 3) fur HDL Leute: kein simulator testbench :( 4) fur SW Leute: ok, etwas delphi source code, aber na parameter uber RS232 senden ist keine magie. fazit: alle sind unglücklich weil sie nicht das sehen was sie kennen/interesse haben. na ich konnte auch keine doku sehen, da ich .ODS dateien nicht öffnen kann. (und bitte, ich will kein openoffice! auf meinen PC) ok, nicht so schlimm, was interessantes ist schon da, aber mit flühtigen uberblick nicht so richtig zu verstehen. -- das DSP, was macht der mit EXTERNEN RAM ? ein audio DSP sollte 1 clock per instruction laufen, da ist ext ram ausgeschlossen. wie werden die DSP algorithmen geschrieben? sollte ein DSP assembler da sein? es ware SEHR gut das DSP mittels delphi program und SignalLab komponent zu simulieren! ok, ich gucke spater noch ein bishen Antti PS ist auf jeden fall zu fruh eine PCB zu bestellen fur den projekt!
Autor:
Rene B.
(themason)
Datum:
sry das ich erst jetzt antworte : zu 1) es gibt einen uC code, aber dieser ist (wie der vhdl-code) nicht wirklich dokumentiert. und bei der masse an code lohnt sich eine doku erst wenn sich genügend leute dafür interessieren. für mich alleine brauche ich keine doku, da das ganze sehr zeitaufwendig ist (hatte ich aber auch schon in diesem thread geschrieben) zu 2) einen "richtigen" dsp code kann man aus den delphi-test-programmen entnehmen, da der code dort über die serielle schnittstelle in den fpga geladen wird. beim uC läuft das ganze ähnlich, wobei mein derzeitiger uC-Code den dsp modular handelt, sodaß uC-seitig nur code-schnipsel in den dsp geladen werden, die dem audio-system dadurch einen modularen "touch" geben. zu 3) testbenches sind für die einzelnen cores vorhanden. bei meiner überarbeitung gibt es weitere testbenches, allerdings keines für den gesamten dsp, da ich mittlerweile auf den ise-simulator umgestiegen bin. zu 4) irrtum, es sind keine "parameter", sondern schon programme, koeffizienten und daten, so wie sie von dem uC aus in den dsp geschrieben werden. die rs232 schnittstelle ist lediglich ein ersatz für den uC, da zum zeitpunkt des enstehens des artikels ich mir die frage gestellt habe : muß ein uC immer vorhanden sein um wenigstens mal ein demo mit dem dsp laufen lassen zu können (daher auch noch kein uC-quell-code, da der artikel nicht up to date mit dem aktuellen stand ist). ich habe mich für .ods entschieden weil ich eben kein excel auf meinem rechner habe und ich das ganze mit möglichst freien tools erstellen möchte. der dsp arbeitet aus dem grunde mit einem externen ram, da sich delay/chorus nicht mit dem internen fpga-block-rams realisieren lassen. weiterhin benötigt das aktuelle design für einen "befehl" (z.b. biquad durchrechnen) deutlich (!!) mehr takte als die original-variante, da der 32x32 multiplizierer serialisiert worden ist (das spart enorm ressourcen auf dem fpga, und macht viele andere dinger überhaupt erst möglich). das durchrechnen eines biquads braucht ca 80 takte (also 5 multiplikationen, 4 additionen, clipping, und das shiften der taps im blockram mit wahlfreien adressen). zum dsp-assembler : im aktuellen uc-quellcode ist ein dsp-assembler/disassembler/memory dump tool mit drin, ein tool mit dem man die audio-module erstellen, modifizieren (also die verbindungen, und die steuerwerte) und auflisten lassen kann. das modular-system wie ich es mir vorgestellt habe läuft also bereits, selbst wenn man es nur per "kommando-zeile" steuern kann. zu früh für ein pcb ist es auf keinen fall, eher schon fast zu spät, da das projekt eben in der zwischenzeit auf meinem mist "gewachsen" (wortwörtlich) ist, und ich wie oben schon beschrieben habe am scheideweg stehe, da noch mehr features eine doku nahezu unmöglich machen, da es wirklich sehr viel geworden ist. ich werde bald mal weitere audio-demos und evtl. video-demos von dem projekt einstellen damit du dir mal ein bild davon machen kannst. den quellcode (uc&vhdl) werde ich mal grob (!!) kommentieren und hier hochladen. vllt wird dann einiges klarer. evtl. überarbeite ich noch den artikel bzw. setze einen neuen auf. muß ich mal schauen. es ist halt nur so das ich eben nicht möchte das die ganze arbeit dann für die "nüsse" ist. dafür würd ich die zeit dann lieber in das projekt selbst stecken. daher auch diese etwas ausführlichere erklärung zum aktuellen stand, damit man versteht warum ich einerseits etwas genervt bin (eben das in 2 jahren kaum etwas zusammen zustande gekommen ist) und ich bisher auch nicht viel zeit in die doku gesteckt habe (wie gesagt weiß ich eben wie das teil funktioniert, und die audio-demos die ich bisher eingestellt habe sind eben nur ein ausschnitt der funktionen des dsps) weil eben so wenig resonanz da ist und ich dadurch eher im stillen für mich gewerkelt habe.
Datum:
Hallo Mason Wirklich interessante arbeit bis jetzt ! 1.) Wär stat einem ARM7 nicht der cortex M3 interessanter ? Aber ich weiß nicht wie es mit der Verfügbarkeit und Programmierung aussieht. 2.) Du könntest ja mal Doxygen drüber laufen lassen über den Code und noch ein paar Kommentare dazu machen ... Aber im großen und ganzen weiter so !!! MFG
Autor:
Rene B.
(themason)
Datum:
zu doxygen mal eine frage : gibt es ein tool mit dem ich die doxygen-kommentare als grundgerüst automatisch erzeugen kann und dann in einem text-editor mit "leben" fülle ? also das z.b. funktionen mit einem doxygen-header versehen werden, am dateianfang automatisch ein doxygen-abschnitt zur kommentierung erzeugt wird ?
Datum:
Wenns um Doxygen geht muss ich leider passen arbeit selbst erst seit kurzen damit! MFG
Autor:
Rene B.
(themason)
Datum:
im snapshot vom svn ist ein "aktuellerer" stand ... aber immer noch nicht der aktuellste ... der muß erst noch kommentiert werden, da ich den wegen dem pcb überarbeitet hab. und dabei ist auch eben ein system bei rausgekommen das einen assembler für den dsp sowie eine modulare steuerung erlaubt. ich werde diesen mal bei gelegenheit im svn updaten.
Autor:
Rene B.
(themason)
Datum:
ich bin dabei eine simulation des ganzen zu schreiben um a) besser testen zu können und b) um den leuten die zwar interesse aber keine zeit haben einen vorgeschmack auf das zu geben was man mit dem dingen machen kann. hardwaremäßig bin ich dabei den atmega644p durch einen atmega1281/atmega2561 zu ersetzen da es ja leider mit dem atmega1284p ja leider noch ne weile dauert, obwohl ich diesen viel lieber eingesetzt hätte (16k ram, offiziell 20mhz, kleines gehäuse, pinkompatibel usw). ansonsten halt immer noch auf der suche nach leuten die mitmachen wollen. es würde mich halt auch mal interessieren ob die leute die damals interesse bekundet haben dieses immer noch haben. es ist halt einfach nur so das ich das ganze freigeben und überarbeiten würde (im sinne einer doku usw) wenn sich eben genügend leute finden, weils eben in diesem stadium des projektes doch sehr zeitaufwendig ist das alles nachzupflegen, und ich es für mich selbst nicht unbedingt brauche.
Autor:
Rene B.
(themason)
Datum:
Es wird mal wieder Zeit meine Arbeiten zu präsentieren : Anbei mal ein Youtube-Link des derzeitigen Standes. Es ist der DAP mit Touch-Display als Effekt Gerät zu sehen. http://www.youtube.com/watch?v=LUvqG7hGzsg Viel Spaß damit. PS. Als nächstes folgen Synthesizer Demos.
Autor:
Rene B.
(themason)
Datum:
Wie angedroht nun noch das Synthesizer-Demo : http://www.youtube.com/watch?v=lSO267qKo14
Datum:
Hallo, erstmal respekt für das bisher geleistete!!! ich lese mich selber erst seit ein paar tagen in das thema FPGAs ein und finde das ganze super interessant aber leider auch extrem abschreckend wenn man sich die datenblätter der einzelnen verfügbaren FPGAs so anschaut. ich würde gern helfen allerdings wird ein noob wie ich da kaum was bringen. eines noch .. gib nicht auf und mach ungebremmst weiter, auch wenn nur benig beteiligung herscht, es gibt sicher zig leute die hier immer mal wieder reinschauen und nur nicht wissen was sie sagen sollen .. wer weiß .. evtl. sind sie ja nur sprachlos :) gruß .. lennart
Datum:
sprachlos..... ;-) wirklich ein sehr schönes projekt. beschäftige mich momentan mit einer risc prozessor implementierung auf einem fpga. sowie eine wenig mit filterbänken mit fir filter sowie ansatzweise wellen digital filter. Viele Grüße und weiter so....
Autor:
Rene B.
(themason)
Datum:
erstmal danke für das feedback. freut mich das mal jemand einen kommentar zu den videos abgibt und danke für das lob. ich werd garantiert an dem projekt weitermachen, zumal ich dieses projekt (ein modulares audio-system) schon seit ca 10-15 jahren vorhab, aber erst ca 2002 die mathe-grundlagen soweit zusammenhatte (damals hab ich eine reine software-lösung gehabt) und seit 2005 mich mit fpga's befasst hab sodass sich erst seit ca 2006 soweit war eine erste version der modularen audio-engine implementieren konnte. @lennart ob noob oder nicht, die grundlagen würde ich schon erklären. bzw hilfestellung geben um das projekt verstehen zu können. das einzige was mich im moment echt davon abhält ne anständige doku zu machen ist einfach der aufwand der sich bei nur wenigen leute leider eben nicht lohnt, da ich das projekt (dadurch das ich da eben schon so lange dran sitze) in und auswendig kenne und es doch schon recht umfangreich ist (es ist ja nicht nur der fpga, sondern auch die uc-software die sehr umfangreich ist). @ralf also ein risc-prozi würd mich auch noch interessieren (vor allem weil ich zu der implementierung eines riscs wahrscheinlich noch etliche fragen hätte, obwohl ich das prinzip schon verstanden habe, aber an einer umsetzung wohl scheitern würde (jedenfalls bei dem was ich mir als ziel setze :-)) es wird bei youtube noch weitere videos geben. erstmal ein video mit einer etwas anderen hardware (zumindest den ui-teil, da gibts dann eine spezielle ui für den synthesizer mit potis, schaltern und leds). ein weiteres video wird die pc-schnittstelle zeigen (mit der sich wirklich ne ganze menge machen lässt, da in den beiden synths bzw systemen ein recht leistungsstarker kommando-interpreter implementiert ist). außerdem wird es noch ein video geben mit einer art "making of" bzw erklärung was da genau in der kiste läuft und wo etwas zu der hardware gesagt wird. bestimmte software-teile werde (bzw hab ich schon) hier in der code-sammlung eingestellt. unter anderem der besagte kommando-interpreter (der in einer älteren version schon hier existiert). aber auch die gui werde ich wohl mal "extrahieren" und in der code-sammlung einstellen. weitere software-teile werden noch folgen. evtl wird auch der artikel "Audio-DSP mit Spartan3 FPGA" überarbeitet. alles mal schauen wie sich was ergibt. jedenfalls danke noch für das feedback.
Autor:
Rene B.
(themason)
Datum:
wie gestern angedroht folgen nun ein paar weitere bilder des audio-prozessors. diesmal im synthesizer gewand. allerdings sind das erstmal nur die bilder. diese sind im artikel "audio dsp mit spartan 3 fpga" zu finden. videos wie live an der kiste geschraubt wird folgen wenn das gehäuse umlackiert und alles soweit eingebaut ist. http://www.mikrocontroller.net/articles/Audio-Projekt
Autor:
Rene B.
(themason)
Datum:
noch eine drohung wahrgemacht .... der grobe aufbau der hardware als youtube-video (allerdings ohne akustische erklärung, sondern nur mit den you-tube anmerkungen). http://www.youtube.com/watch?v=rVAdz9dzrIg
Autor:
Rene B.
(themason)
Datum:
So. Da ich ein sturer Hund bin Frage ich nochmal nach : - Gibts Leute die an einem solchen Projekt mitarbeiten möchten ? - Gibts Leute die diese Platform als Bausatz kaufen würden ? Die zweite Frage zielt ein wenig darauf ab das ich überlege die Platine als Bausatz (vormontiert) verkaufen zu wollen. Das ist erstmal eine grobe Idee, weil wenn nicht genügend Leute Interesse an so einem Bausatz hätten wäre der Aufwand zu groß, bzw wirds mir zu teuer. Was bietet diese Platform ? Es ist im Prinzip ein ganz normales FPGA-Board, nur etwas spezieller auf Audio zugeschnitten. Bei dem momentanen "Flagschiff" beinhaltet das Board 2 Stereo Codecs (einen TLV320AIC23B und jeweils einen CS4344 und CS5343), 16MB SDRAM, einen AVR ATMega2561, µSD Card Slot, ein Atmel DataFlash, ein serielles EEProm sowie RS232, MIDI und div. Stiftleisten im 2,54mm Raster. Es lassen sich damit Audio-Anwendungen zusammenbauen, aber auch andere Applikationen sind denkbar (beispielsweise Logic-Analyzer, Mini-Computer, ...) Zu den Audio-Anwendungen die ich bereits realisiert habe : - Synthesizer - Effektgerät - kl. Mischpult Zu dem was noch kommen kann/wird - div. Syntheseverfahren (additiv, FM, Granular) - Harddiskrecording (SD/CF/HDD) - Kompressor/Expander Wie siehts aus mit Doku ? Im Moment gibt es noch keine, da ich erstmal rausfinden möchte ob überhaupt Interesse an einem solchen Board besteht. Dokumentation für mich selbst macht keinen Sinn, aber wenn genügend Leute so ein Board haben wollen wird diese ebenfalls noch erstellt. Wie teuer wird das ganze ? Dazu kann ich leider noch nichts sagen da es in erster Linie davon abhängt wieviele Leute so ein Board haben möchten. Der Teuerste Posten ist und bleibt der FPGA mit 25€ (bei Reichelt, Einzelstückzahlen) und dieser wird auch nicht viel günstiger (selbst in Stückzahlen bei Digikey gibts den nicht wirklich unter 19€). Das zweit-teuerste ist die Platine, gefolgt vom AVR und den Codecs. Alles in allem dürften es um die 100€ Materialkosten sein (wahrscheinlich weniger, da in Stückzahlen die Preise für Platine, Codecs, AVR eher runtergehen als die des FPGA's)
Datum:
Hi, ist jetzt leider schon eine weile her seit zu dem Projekt was geschrieben wurde. but anyway. Ich hätte auf jeden Fall Interesse an dem Projekt. Zunächst leider nur aus Anwendersicht, da ich mit Mikrocontrollern im Allgemeinen und mit FPGAs im speziellen wenig/keine Erfahrung habe. Ich könnte dem Projekt nur soweit helfen, dass ich weiß welche Features für die Praxis sehr vorteilhaft wären (ich bin nebenberuflich als Veranstaltungstechniker/Tontechniker unterwegs) Daher kenne ich auch die Systeme die im professionellen Umfeld eingesetzt werden und leider auch deren Preise :-( Deshalb bin ich sehr an einem openSource Projekt interessiert. Kann man im aktuellen Stadium einen mehrkanaligen Equalizer realisieren (also zb. auf 12 Frequenzbändern?). Wie hoch können die Samplingfrequenzen aktuell maximal sein (für einen in der Praxis tauglichen Einsatz sind 48kHz oder mehr zwingend nötig (nicht nur im proAudio Bereich)) Wäre super wenn du dich hier (oder per twitter @7tupel) bei mir melden könntest. lg 7tupel
Autor:
Rene B.
(themason)
Datum:
@7tupel Das Projekt "lebt" noch. Allerdings bin ich mehr für mich alleine am werkeln, da sich eben nicht genügend Leute für eine Sammelbestellung einer der Varianten finden lassen. Ich fang mal von hinten an ... - 48kHz kein Problem (läuft zur Zeit auch) - mehrere Eingangskanäle kein Problem (habe max 4 mono bzw 2 stereo ein/ausgänge) - 12 Kanal Equalizer pro Kanal wird bei dem derzeitigen Design und verwendeten FPGA schwierig. Ich plane ohnehin ein Redesign allerdings noch ohne konkrete Vorstellungen, da das Projekt im Moment etwas hinten ansteht. Das einzige was ich zur Zeit mache ist zu versuchen meinen Synthesizer damit endlich mal fertig zu bekommen. Ich hab einfach zuviele Ideen die ich da reinprügeln will :-)), daher muß ich mal aufräumen. Für Anregungen, Erweiterungen und Kritik bin ich aber dennoch offen. Ist halt nur schade das man nicht einmal ne Sammelbestellung hinbekommt. Du kannst mir auch gerne per uc.net schreiben. Bin ja hier angemeldet. Bei twitter bin ich nicht angemeldet.
Datum:
Ich bin an diesem Projekt auch sehr interessiert, da ich mit Audio-DSP schon viel auf PC-Basis gearbeitet habe. Hatte bisher nur noch nicht mit FPGAs zu tun, aber wollte damit irgendwann mal anfangen, allerdings ist der Einstieg bei diesen Dingern nicht so leicht. Schön wäre es, wenn das Projekt (das neue Board) modular aufgebaut wäre ähnlich wie bei den Midiboxen, sodaß man eine Core-Platine hat, auf der nur das nötigste ist, also FPGA und alles was er zum laufen braucht + Codecs, und dann eigentlich nur noch Header. Das reduziert auch den Preis für die einzelnen Projekte, weil man für bestimmte Projekte nicht ständig ein komplettes Board mit unnützen Kram braucht. Was für mich allerdings noch wichtiger wäre, ist eine Art Anleitung wie man ein Demoprojekt (zB. einfache Lautstärkeregelung) erstellt und auf das Board überträgt (und man sollte da nicht vergessen zu erwähnen, was man dafür alles benötigt).
Autor:
Rene B.
(themason)
Datum:
@maik Das neue Board ist sozusagen ein Core-Board mit FPGA, SDRAM, Codecs, Schnittstellen, uC, SD-Karte, EEProm, DataFlash und viiiiielen Headern. Da wäre nichts weiter modular zu machen. Es bleibt im prinzip jedem selbst überlassen ob er Potis, Encoder, Subsystem mit Touchdisplay oder oder oder anschließt. Allerdings ist es halt auch recht anspruchsvoll zu löten bzw zu programmieren. Wenn ich wirklich wüsste das ich sagen wir 10 Leute zusammen bekomme bzw 10 Bausätze, dann könnte man echt über eine Sammelbestellung nachdenken, bzw würd das ganze halt mal durchrechnen. Allerdings sind die Bauteilkosten auch sehr hoch. Alleine für die Bauteile gehen bestimmt an die 100 Euro drauf. Platine auch nochmal ca 50 Euro. Und wenn ich jemandem eine Platine zusammenlöten soll auch nochmal ein paar Euros. Im Prinzip ist diese Platine ja auch nicht auf Audio beschränkt, da fast alle Pins des FPGAs nach draußen geführt sind (genauso wie beim uC). Von daher find ich es schon etwas schade das da so wenig Resonanz ist. Aber einen genauen Preis kann ich eben nicht nennen, da es sehr stark davon abhängt wieviele mitmachen. Und wenn ich sagen würde zw 200-250 Euro für alles komplett aufgebaut wäre es zuviel. Das dann aber nur evtl 2-3 Leute mitmachen steht dann auf einem anderen Blatt. Na ja. Mal schauen. Vllt finden sich ja noch genügend Leute. Dann würde wie schon mehrfach beschrieben auch eine Anleitung bzw eine ausführliche Dokumentation Sinn machen, zumal der eigentliche DSP sehr einfach zu programmieren ist. Gruß
Datum:
also wenn sich noch ein paar mehr Leute finden und das Projekt (ins besondere auch die Doku) voran kommen, dann wäre ich durchaus bei einer Sammelbestellung mit dabei. Ich werde auch bei mir im hackerspace (www.hackerspace-ffm.de) einmal rumfragen ob dort noch jemand Interesse hat. lg 7tupel
Autor:
Rene B.
(themason)
Datum:
@mo ich hoffe ja immer noch darauf das sich noch ein paar Leute finden. (selbst nach fast 4 Jahren geb ich die Hoffnung nicht auf :-))) Dann würde ich mir auch die Mühe der Doku machen, Code-Schnipsel und und und bereitstellen. Nur für mich alleine macht es wenig Sinn. Ich kenne das System ja. Und nur um dann nen PDF zu haben das beim nächsten Redesign (tlw) hinfällig ist lohnt es sich nicht. Ich habe mal im Unterforum "Markt" einen Thread erstellt wo man sich eintragen kann. Beitrag "[S] Leute die an einem Audio-Projekt interessiert sind" Diejenigen die ich anschreiben kann (Anmeldung) werd ich mal antexten, und dann mal schauen wieviele Leute ich zusammenbekomme. Ich denke ab 10 Leuten wirds interessant. Wie gesagt : Doku würde ich machen. Zumal durch das Redesign vor ca 2 Jahren hat man auch mehr Platz und mehr Features die dann ohnehin Dokumentiert werden müssten.
Datum:
Ich glaube, du solltest ein paar mehr DSPs in so ein board stopfen, dann können es auch Leute verwenden, die Video oder anderes damit machen wollen.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten