Seid gegrüßt, Ich habe etwas den Überblick über den DSP Markt verloren. Gesucht wird ein leistungsstarker DSP (Maßstab: Audio Processing), der viel FIR Processing, aber auch Netzwerkkommunikation, Limiting und sonstige Berechnungsaufgaben (z.B. RMS Integration) können soll. Aktuell scheint ein Kandidat der ADSP SC589 zu sein. Die Merkmale der anderen Kandidaten sollten ähnlich sein. Die Leistungsaufnahme ist relativ egal, das P/L Verhältnis ist natürlich das Hauptkriterium, ein uC sollte nicht mehr als 60€ (80€, falls nötig) bei 100er Abnahmen (Kleinserie) kosten. Für jede Hilfe wäre ich sehr dankbar! Beste Grüße
Dein Name sagt mir das wir in der gleichen Branche arbeiten, aber das nur am Rande :) Warum alles nochmal neu erfinden? Was ist falsch an existierenden Lösungen z.B. mit SHARCs? Definiere bitte mal "viel FIR".
Die existierenden Lösungen geben mir alle nicht die Flexibilität, die
ich brauche. Da sowieso die ganze Elektronik selbst designt ist, kann
man es auch direkt richtig machen.
Letztendlich habe ich 7 einzelne Kanäle, die alle eine aufwendige
Entzerrung ("Grundidee" des Projektes hängt davon ab) erhalten, die
Anzahl der Taps kann ich nur schätzen, wird insgesamt aber sich so bei
10000 oder mehr liegen.
Was ist denn hier mit Entzerrung gemeint? Ich nehme an ein EQ für 7 LS im Array?
Nein. Delay, Amplitudenanpassung, Phasenanpassung. Darin inbegriffen ist die Filterung nach oben/unten sowie das Equalizing.
Nunja, hatte erst kürzlich ein Projekt durchgerechnet, ein Eingang und 4 Ausgänge, die ganzen Standards in jedem Ausgangskanal (EQs, Delay, Crossover, RMS- und Peak Limiter,...) das Gleich im Eingang und dazu ein FIR mit 2048 Taps der dann in der Summe Frequenz und Phase linearisiert. Das ganze bei 96kHz und selbst mit einem kleinen ADAU1452 gerade mal bei 38% Auslastung laut Sigma Studio. Wenn du nicht exorbitante Delayzeiten hast (was in einer Aktivbox kaum vorkommen dürfte) kommst du da selbst mit kleinen DSPs und internem RAM locker hin. Ein ADAU1452 verkraftet laut Datenblatt 24000 FIR Taps oder 3000 Biquads bei 48kHz. Das ist ne Menge Holz...
Hallo Thomas, wie kommen die 24000 FIR-TAPs zustande? Ich habe mir das Datenblatt mal angesehen: Bei der Frequenz von 294912000 (offenbar 1536x192k) wären das je 48000Hz Sampletakt 6144 Netto-TAPs. (steht auch so in der Tabelle). Für 2 Kanäle (Stereo) ergäbe das eine Filterlänge von 3072 und damit ein span von 1/15,6 Hz. Das ist schon knapp, wenn es um gute Bass/DC-Prozessierung geht. Mit 96000 kommt man nicht hin, oder hat der mehrere Kanäle parallel? - Stereo?
Angehängte Dateien:
-
schematic.png
200 KB -
summary.png
13 KB
Hallo Jürgen, anbei mal die Ausgabe von Sigma Studio und die dazugehörige Schematic. Für den FIR mit 2048 taps hat er 2x 2048bytes Speicher reserviert, benötigt aber nur 521 Befehle.
:
Bearbeitet durch User
wenn du erstmal eine vollständige Platine suchst wäre ein E-Gitarren Verstärke die richtige Quelle aud den Line6 Spider IV Geräten sollen diese Sharx DSP verbaut sein gratis dazu gibt es einen Monoverstärker. Denke mit 40€ kann man schon den kleinen mit 15W erwerben.
Thomas O. schrieb: > wenn du erstmal eine vollständige Platine suchst wäre ein E-Gitarren > Verstärke die richtige Quelle aud den Line6 Spider IV Geräten sollen > diese Sharx DSP verbaut sein gratis dazu gibt es einen Monoverstärker. Ich habe nicht umsonst einen link auf das MiniDSP-System gesetzt. Das ist die Plattform mit der die meisten Hersteller auch von professionellen Systemen heute arbeiten. > Denke mit 40€ kann man schon den kleinen mit 15W erwerben. Einstieg mit $99,-
Line Array schrieb: > Die Leistungsaufnahme ist relativ egal, das P/L Verhältnis ist natürlich > das Hauptkriterium, ein uC sollte nicht mehr als 60€ (80€, falls nötig) > bei 100er Abnahmen (Kleinserie) kosten. Was spricht eigentlich gegen nen Cortex-M4, der pi mal Daumen nen Zehner kostet? FPU gibt's je nach Chip gleich dabei. Mit 168 MHz und 192kB RAM ist da einiges möglich.
Thomas F. schrieb: > anbei mal die Ausgabe von Sigma Studio und die dazugehörige Schematic. > Für den FIR mit 2048 taps hat er 2x 2048bytes Speicher reserviert, > benötigt aber nur 521 Befehle. Dann scheint er wohl einiges parallel zu machen oder es ist eine Kaskade. Müsste man jetzt mehr über den Filter und die Struktur wissen. Allerdings kriege Ich es noch nicht ganz mit der Tabelle in der SPEC überein. Wie auch immer... Die andere Frage wäre, ob bei 96kHz 2024 TAPs reichen. Dabei werden etwa 20 ms erfasst. Davon ausgehend, dass in den Koeffizienten ein Fenster steckt, wäre das ein Filter mit 50 Hz. Passt das für die Applikation? Ich habe in meinem Audio-DSP (was FIR angeht) symmetrische Filter drin, brauche also für 1024 TAPs jeweils 512 Additionen + 512 Multiplikationen und die Akku. Ausgelegt sind die mit einem Fenster über mindestens 2 Perioden bei 20Hz, also >100ms. Bei 96kHz dann in Richtung 16384 TAPs. Hi-Tech-Progger schrieb: > Ich habe nicht umsonst einen link auf das MiniDSP-System gesetzt. Das > ist die Plattform mit der die meisten Hersteller auch von > professionellen Systemen heute arbeiten. So? Da gibt es aber schon noch andere, Hypex z.B. und bei Weitem nicht alle Hersteller arbeiten mit solchen OEM-Modulen, sondern haben eigene Lösungen und dies nicht nur auf DSP-Basis. Nop schrieb: > Was spricht eigentlich gegen nen Cortex-M4, der pi mal Daumen nen Zehner > kostet? DSPs sind schon in Richtung Audio und den Anforderungen optimiert und so viel teuer auch nicht.
Jürgen S. schrieb: > DSPs sind schon in Richtung Audio und den Anforderungen optimiert und so > viel teuer auch nicht. Aber es war auch was mit Netzwerk gefordert, und das können DSPs eher nicht. Ist halt die Frage, ob die ADC/DAC eines M4 für Audio ausreichend gut sind. 10 Bit ist ja nun wirklich nicht der Hit, evtl. müßte man dann externe Bausteine vorsehen.
Nop schrieb: > 10 Bit ist ja nun wirklich nicht der Hit Die meisten (alle? gibt so viele) STM32F4 haben 12 Bit.
2⁵ schrieb: > Die meisten (alle? gibt so viele) STM32F4 haben 12 Bit. OK, aber das ist immer noch deutlich unterhalb der 16 Bit einer CD, und wenn man dann noch Rauschen für die Verarbeitung einrechnet, müßte man eigentlich schon mit deutlich mehr als 16 bit abtasten und verarbeiten. 20 bit, vielleicht 24. Andererseits, haben DSPs wirklich so hochauflösende AD-Wandler an Bord? Würde zumindest die Preisvorstellung des OP erklären. Aber die DSPs sehen dann bei Netzwerk nicht gut aus, so daß dedizierte AD/DA-Wandler an nem M4 vielleicht eine Idee wären.
Nur mal als Referenz, die Preise von China-SOCs: https://www.olimex.com/Products/Components/IC/ Zur Verfügbarkeit: https://olimex.wordpress.com/2014/11/27/how-long-olinuxino-with-allwinner-socs-will-be-produced-again-now-we-know-the-answer-forever/
Jürgen S. schrieb: > Die andere Frage wäre, ob bei 96kHz 2024 TAPs reichen. Dabei werden etwa > 20 ms erfasst. Davon ausgehend, dass in den Koeffizienten ein Fenster > steckt, wäre das ein Filter mit 50 Hz. Passt das für die Applikation? Die meisten DSP für professional Audio haben maximal 2048 oder 4096 Taps, weil du aus praktischen Gründen nur ab etwa 300Hz anwenden kannst. Das Problem ist die Gruppenlaufzeit. Wenn du jetzt als Anwendungsbeispiel einen DSP für einen aktiven Lautsprecher, sagen wir als Bühnenmonitor, einsetzt dann kannst du dir keine Gruppenlaufzeiten von 30ms, 40ms oder nochmehr leisten, weil dann durch die Verzögerungen das Teil unbenutzbar wird. Im heimischen Wohnzimmer spielt sowas keine Rolle, man merkt dann bei extremen Verzögerungen höchstens irgendwann das das Audiosignal nicht mehr lippensynchron ist. :-)
Nop schrieb: > Was spricht eigentlich gegen nen Cortex-M4, der pi mal Daumen nen Zehner > kostet? FPU gibt's je nach Chip gleich dabei. Mit 168 MHz und 192kB RAM > ist da einiges möglich. Und der soll 10000 taps bei 96kHz können? Denk nochmal darüber nach :) 10000 taps hört sich für mich so an, als wäre es sinnvoller, mit Multirate Filterbänken zu arbeiten. Die vielen taps braucht man in der Regel ja nur wegen der Schmalbandigkeit bei der hohen Sample-Rate bei den tiefen Frequenzen. Man kann zB mit perfect-reconstruction-Filtern das Frequenzband kaskadiert in jeweils 2 Bänder trennen, die dann - dank Nyquist^^ - nur jeweils die halbe Samplerate der letzten Stufe haben. Da kommen dann auch polyphase Dezimatoren und Interpolatoren ins Spiel - die kann man sich aber von Matlab berechnen lassen. https://de.mathworks.com/help/dsp/examples/reconstruction-through-two-channel-filter-bank.html Hatte das mal spaßeshalber in VHDL implementiert ... Ist aber schon lange her und nicht weiter genutzt.
:
Bearbeitet durch User
asdfasd schrieb: > Nur mal als Referenz, die Preise von China-SOCs: > > https://www.olimex.com/Products/Components/IC/ Oergs. Ich weiss ja nicht, aber zumindest mit dem 'Allwinner'-Kram würde ich nix selber entwickeln wollen. Die Systeme die ich bisher gesehen habe, waren wenig robust und dokumentiert. Und die Preise sind jetzt nicht der Wahnsinn. Bei den Stückzahlen im Nicht-Consumer-Bereich würde ich gemessen an den Entwicklungskosten immer noch zu nem Blackfin greifen, schlussendlich arbeitet man für diese Anwendung sowieso auf "bare metal". Habe aber die Angaben des TO nicht durchgerechnet, kann knapp werden, bzw. müssen allenfalls die Kanäle auf mehrere DSPs aufgeteilt werden.
Mampf F. schrieb: > Und der soll 10000 taps bei 96kHz können? > > Denk nochmal darüber nach :) Uuuhh.. jetzt, wo Du es sagst. Der M4 müßte dann wohl mit 960 MHz laufen, wenn MAC in einem Takt geht, aber die ganzen MACs sequentiell ablaufen.
Nop schrieb: > Uuuhh.. jetzt, wo Du es sagst. Der M4 müßte dann wohl mit 960 MHz > laufen, wenn MAC in einem Takt geht, aber die ganzen MACs sequentiell > ablaufen. ... oder parallel arbeiten. Nop schrieb: > Aber es war auch was mit Netzwerk gefordert, und das können DSPs eher > nicht. Hm, "Netzwerk" hatte Ich so gelesen, daß es um die Vernetzung der Array Elemente, also der Lautsprecher ging. Das ist nicht unbedingt ETH. Kann natürlich sein, daß der TO seine Sachen per Ethernet konfigurieren will. Wäre jetzt die Frage ... Thomas F. schrieb: > Die meisten DSP für professional Audio haben maximal 2048 oder 4096 > Taps, weil du aus praktischen Gründen nur ab etwa 300Hz anwenden kannst. > Das Problem ist die Gruppenlaufzeit. Für diesen Anwendungsfall gebe Ich Dir Recht. FIR sind immer ein Problem, was die Verzögerung angeht. Da böten sich z.T. Kombinationen mit IIR für den Bassbereich an. Sowas habe Ich mal für ein System realisiert. Damals noch mit 90er-Jahre DSPs :-) Ansonsten muss man Rechnen: Die Verzögerung für Signale um die 20Hz wären für Lambda/2 (als Minimum genommen) 25ms und entsprächen 10m. Für die Steuerung von LS in Entfernung der Bühne braucht es ohnehin eine passende Verzögerung. Damit sind die ab etwa 7-8m wieder interessant und einsetzbar. Ich hatte in meiner damaligen Applikation den Filter mal direkt so ausgelegt, daß es das Delay weitgehend alleine packt, ohne Zusatz-RAM. (Die Positionen der Lautsprecher waren bekannt und statisch verbaut).
Mampf F. schrieb: > 10000 taps hört sich für mich so an, als wäre es sinnvoller, mit > Multirate Filterbänken zu arbeiten. Für DSPs und die Anforderung, mit möglichst wenig Resourcen auszukommen, ist das sicher zu bedenken, aber: > Man kann zB mit perfect-reconstruction-Filtern das Frequenzband > kaskadiert in jeweils 2 Bänder trennen, die dann - dank Nyquist^^ - nur > jeweils die halbe Samplerate der letzten Stufe haben. Diese -> Halbbandfilter haben so ihre Tücken, insbesondere bei der Annahme mit Nyquist und fs/2. Das stimmt so nur in der digitalen Domain. Für die Audioanwendungen ist das nicht unbedingt tauglich. Was man tun kann, ist, die Kaskadenelemente auf jeweils ein Viertel der Frequenz zu designen und trotzdem mit der halben abzutasten. Das spart aber nicht mehr viel oder ist kontraproduktiv. > Hatte das mal spaßeshalber in VHDL implementiert ... Ist aber schon > lange her und nicht weiter genutzt. Ich habe da auch so meine Experimente und Messungen hinter mir und gerade in FPGAs muss man schauen, wo man bestimmte Zwischenergebnisse über mehrere Zeitebenen nutzen kann, um sich Zwischenspeicherungen zu sparen, weil die Platz kosten, während es beim DSP Zeit kostet. Daher sehen die Implementierungen im FPGA anders aus. Ähnlich verhält es sich bei den Elementen in den Spezial-ASICs: Die sind schon dafür gebaut, so zu multiplizieren. Bei Grafikarten und DSPs dürfte es ähnlich aussehen. Es ist auch eine Frage der Verwaltung eines Filtersystems und seiner Änderbarkeit und Parametrierbarkeit, ob man da eine komplizierte Struktur vorsehen sollte. Ein einfacher Multiplier im Artix packt heute in fabric!!! an die 200MHz und rotiert bei 192kHz Abtastrate eben schon mal 1000 Taps durch. Die Schaltung ist damit so winzig, dass man sie etliche Hunderte mal ins FPGA bekäme und trotzdem die Hunderte Multiplier noch frei hätte. Als constant coefficient sind die auch klein und effektiv. Als echter Multiplier mit freien Koeffizienten kann man das auch in Echtzeit ändern, wenn man die Koeffizientenberechnung selbst in den DSP verlegt. In einem FPGA kann man die Koeffizientenberechnung parallel als pipeline bauen und just in time der Rechenpipeline zuführen. Damit ist das für jedes Sample änderbar. Das kann man dazu nutzen, eine Filterpipeline für mehrere Kanäle zu verwenden oder aber über die Zeitachse zu manipulieren. Meine Pyratone nutzt das als "Soundmorph"-Klangeffekt.
Strubi schrieb: > Oergs. Ich weiss ja nicht, aber zumindest mit dem 'Allwinner'-Kram würde > ich nix selber entwickeln wollen. Die Systeme die ich bisher gesehen > habe, waren wenig robust und dokumentiert. Taugt aber gfs als Prototype-Platform. Die Chinesen sind einfach unfassbar billig. Ich habe mir eine Anzahl von S/PDIF-Wandler und DACs geholt, um Testaufbauten zu machen. Für die 23,99, was die Pakete typisch kosten :-) kriegst Du 4-6 Platinen und die kann man nicht selber bauen. Der Weg zur Post, um sie abzuholen ist von der Zeit her schon teurer :-) Generell wäre ein richtiges komplettes Audio-System mit DSP und Peripherie eine nette Sache! Bis 2005 konnte man z.B. die Chameleon kaufen, ein System für 56303-Prozessoren, die in denr 90ern der Renner waren und überall verbaut worden sind. http://www.96khz.org/htm/chameleonsynth.htm Damit liessen sich eigene Entwicklungen machen und man konnte es direkt ins Rack schrauben! Keine Ahnung, ob es heute was Vergleichbares gibt. Ich kenne für die aktuellen DSPs nur die Evalboards der Herstellern und die haben keine ausreichende Peripherie oder Umgebung und auch keine Community die es supported.
Jürgen S. schrieb: > Taugt aber gfs als Prototype-Platform. Die Chinesen sind einfach > unfassbar billig. Ich habe mir eine Anzahl von S/PDIF-Wandler und DACs > geholt, um Testaufbauten zu machen. Für die 23,99, was die Pakete > typisch kosten :-) kriegst Du 4-6 Platinen und die kann man nicht selber > bauen. Der Weg zur Post, um sie abzuholen ist von der Zeit her schon > teurer :-) > Ich sag ja nix, ich kauf auch gern bei DX, Banggood, und was sie alles für lustige Namen haben. > Generell wäre ein richtiges komplettes Audio-System mit DSP und > Peripherie eine nette Sache! Bis 2005 konnte man z.B. die Chameleon > kaufen, ein System für 56303-Prozessoren, die in denr 90ern der Renner > waren und überall verbaut worden sind. > http://www.96khz.org/htm/chameleonsynth.htm > > Damit liessen sich eigene Entwicklungen machen und man konnte es direkt > ins Rack schrauben! Was hältst du vom Ansatz, ein (oder mehrere) 56k-Design(s) in ein grösseres FPGA zu verbacken? Ich höre immer mal wieder von 56k-ASM-Veteranen, dass sie an sowas Interesse hätten. Aber die kritische Masse fehlt noch, wenn's ans Finanzieren geht... Die Tools drumrum sind ev. auch ein Haken, aber mit dem ollen a56 von Quinn Jensen geht noch was (hier liegt noch ne alte Turtle Beach mit ISA bus und 56k...ich bring's nicht übers Herz.) > Keine Ahnung, ob es heute was Vergleichbares gibt. > Ich kenne für die aktuellen DSPs nur die Evalboards der Herstellern und > die haben keine ausreichende Peripherie oder Umgebung und auch keine > Community die es supported. So richtig gute Baukastensysteme wie früher habe ich auch nicht mehr gefunden. Es gab immer mal wieder kleine Grüppchen von Leuten, die nette Effekte auf dem BF533 EZKIT implementiert haben. Auf Messen tauchten auch immer wieder ähnlich interessante Boards auf, und verschwanden genauso schnell wieder in der Versenkung, wenn man sie wirklich haben wollte. Der Blackfin ist allerdings mit seinen 16x16 Multipliern für Audio etwas unsexy.
Martin S. schrieb: > Was hältst du vom Ansatz, ein (oder mehrere) 56k-Design(s) in ein > grösseres FPGA zu verbacken? Ich höre immer mal wieder von > 56k-ASM-Veteranen, dass sie an sowas Interesse hätten. Aber die > kritische Masse fehlt noch, wenn's ans Finanzieren geht... Das wäre natürlich ein Thema, so einen Emulator auf die Beine zu stellen, nur: 1) baut man einen 563xx-er mit all seinen Optionen Interrupts Memories und was weiß Ich nicht alles, nicht mal so eben zusammen und bringt es 100% lauffähig hin. Das muss ja für alles und jeden passen. 2) Ist die Architektur mit 24 Bit inzwischen weitgehend überholt und das nicht nur, was FPGAs oder DSPs angeht. 3) Ist der Wert wohl gering, weil die meisten Anwendungen (auch meine eigenen) auf C und nicht auf Assembler entwickelt sind und damit recht gut auf andere DSPs portierbar waren und sind - abgesehen von etwas Coldfire Assembler. Will heissen: Die, die Code habe und hatten, haben ihn schon woanders laufen. 4) damit ist das Problem noch immer nicht gelöst ist, dass eine Audio-HW mehr ist, als nur der Prozessor und Peripherie benötigt. Gerade am Punkt 4 kranken ja die Evalboards, die man zu erschwinglichen Preisen bekommt und die ein Nutzer nicht so ohne Weiteres einsetzen kann und daran krankte auch meine damalige DSP-Plattform mit dem TMS320 mit dem Ich mal begonnen habe, Audio machen. Ich habe dafür sehr viel entwickelt, nicht nur Klangsynthese sondern auch Audio-Verarbeitung und Lautsprechersteuerung. Daher war es ja so ein großer "Wurf", ein komplettes Studiogerät für 500,- Euros von einem Drittanbieter zu bekommen, das komplett fertig ist, von Nutzern und Programmierern erworben worden und direkt benutzt werden konnte. Das hatte das Meiste Potenzial und hat sich trotzdem nicht durchgesetzt, weil es eine UAD-1 und eine SoundScape Mixtreme gab, die denselben Prozessor hatten und die preisgünstig im PC saßen, mit dem Viele eben besser arbeiten konnten. Die Zeit fürs outboard equipment war eben Mitte der 2000er schon vorbei, als die PCs besser wurden. Heute kaufen selbst die zahlungsfähigen Studiobetreiber kaum noch digitales outboard der Mittelklasse, weil die CPU-Prozessoren das so ziemlich auch schon können. Nur in der Oberklasse in den Audio-Renderfarmen und großen Digitalkonsolen von z.B. SSL finden sich noch dedizierte Audio-HW-Plattformen. Ich sehe da wenig Chancen. Wenn, müsste da eine Diplomand ran und ein halbes Jahr investieren und dann ein weiterer und eine Audio-Plattform basteln. Kommerziell ist da aber nix zu holen, denke Ich. Wer da was Besonderes braucht, greift schon eher zu einem aktuellen DSP, weil der auch digitale Schnittstellen kann, einen S/PDIF Controller intus hat, ect. Solche Funktionen haben ihren Wert. Es waren auch genau solche Überlegungen, die mich seinerzeit zu den FPGAs gebracht haben, um eben S/PDIF mehrkanalig zu haben (hatten nur Profiaudiokarten), ADAT zu machen, mehrkanaliges, hochaufgelöstes MIDI (geht heute gerade mal mit USB 2.0 einigermaßen) und vor allem hochaufgelöste Klangsynthese auf 96kHz+ (hatte damals kein einziger Synth). Wenn Ich mir das mit dem SigmaStudio so ansehe, wie rasch man da durchaus taugliche Systeme zusammenklicken kann, wird man schwerlich jemanden finden, der sich für ein FPGA-remake eines 56ers interessiert, wo noch alles per Hand gemacht werden muss und man weniger hineinbekommt. Diejenigen, die noch Code von damals haben und nichts modifizieren wollen oder können, kaufen sich beim EBAY die entsprechenden Karten, die es für einen Appel und ein Ei gibt. Mit einer Entwickler-Lizenz kannst Du da selber Code reinhacken und seit Sydec übernommen wurde, sind die herzlich billig. Ich habe hier sowohl einige Mixtreme-Karten, als auch UAD in den Rechnern stecken und eben auch die besagte Chameleon einsatzfähig herumliegen, um meine alten Sachen laufen zu lassen und 90er Jahre Techno zu machen :-) Ansonsten ist das alles längst portiert - zunächst in VST-plugins und letztlich ins FPGA. Dort halt für die Architektur optimiert unter Nutzung der FPGA-spezifischen Randbedingungen. Einen 56300-er FPGA-Emulator sehe Ich nicht. Die Dinger liefen ja selber schon auf 120MHz und viel mehr kriegt man im FPGA auch nicht hin. Von der Architektur mehr, als zwei oder drei in einen FPGA zu stecken dürfte auch kaum möglich sein.
:
Bearbeitet durch User
Jürgen S. schrieb: > 1) baut man einen 563xx-er mit all seinen Optionen Interrupts > Memories und was weiß Ich nicht alles, nicht mal so eben zusammen und > bringt es 100% lauffähig hin. Das muss ja für alles und jeden passen. So ist es nicht gedacht...es geht eigentlich nur um die 56002-Kern-Kompatibilität, alles Interrupt-Zeug ist nicht drin und soll auch nicht rein, das erledigt die Front-End-CPU per DMA. Es ginge nur darum, gewisse zwingend in ASM geschriebene Kernroutinen gleich ablaufen wie im Original. Alles andere wäre viel zu aufwendig. Der eigentliche DSP-Kern existiert auch bereits schon und ist 56k-ähnlich. Man müsste da also nicht von Null anfangen, nur sehr viel regress-testen. Wenn Du sowieso alles in C portiert hast, gebe ich Dir recht, macht keinen Sinn. Und wenn du 32 bit-Tiefe oder mehr brauchst, dann bist du eh schnell beim custom-Akku/Multiplier im FPGA. Studio-Sachen sind eh völlig aussen vor, da ist IMHO nix mehr zu holen. Ich denke eher an kleine Musikbuden, die schon lange im Geschäft sind und vom 56k nicht wegwollen. Auch die Sigma-Studio-Geschichte ist nicht zu schlagen, das sind schon geile Tools, bei solchen klassischen Audio-Chains ist auch gegen grafisches Programmieren nix einzuwenden. Mir geht es eher um keep-it-simple-Sachen, die bühnentauglich sind und immer funktionieren, sowas im Stil eines einfachen Gitarreneffektgeräts oder wenns etwas mehr sein darf a la Kemper Amp. Dafür geben meine Musikerkollegen auch gerne mehr aus.
Strubi schrieb: > asdfasd schrieb: >> Nur mal als Referenz, die Preise von China-SOCs: >> >> https://www.olimex.com/Products/Components/IC/ > > Oergs. Ich weiss ja nicht, aber zumindest mit dem 'Allwinner'-Kram würde > ich nix selber entwickeln wollen. Die Systeme die ich bisher gesehen > habe, waren wenig robust und dokumentiert. Es gäbe noch diesen: https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-6-processors/i.mx-6quad-processors-high-performance-3d-graphics-hd-video-arm-cortex-a9-core:i.MX6Q Der ist gut dokumentiert. Aber: Filter (Echtzeit) sind mit Liunx unrealistisch. Man müsste bare-metal rangehen. Vermutlich dürfte immerhin die Rechenleistung reichen. Ich vermute mal, es wird schon einen Grund haben, warum das nicht gemacht wird.
Zeigstl schrieb: [i.MX6Q] > Der ist gut dokumentiert. Ja, bis auf den Bug im ESAI, durch den man kein TDM8 mit 96 kHz aus dem Audiointerface rausbekommt, da die maximal mögliche Bitclock entgegen der Datenblattangaben irgendwo knapp über 20 MHz liegt. Hat uns einiges an Nerven gekostet...
Holger B. schrieb: > Ja, bis auf den Bug im ESAI, durch den man kein TDM8 mit 96 kHz aus dem > Audiointerface rausbekommt, Dann nimm 48kHz, das spart Strom und Leistung. Der Qualitätsgewinn bei 96kHz wird ohnehin allgemein überschätzt.
Audiomann schrieb: > Der Qualitätsgewinn bei > 96kHz wird ohnehin allgemein überschätzt. Ich würde noch weiter gehen. Welcher Qualitätsgewinn bei hörbarem Audio? Wenn man 96kHz für die Filter braucht kann man auch Upsampling nutzen. Wer Audio mit mehr als 48kHz hört, hat das Abtasttheorem nicht verstanden.
Danke für die Tipps, aber es geht hier nicht um vermeintlichen Qualitätsgewinn mit 96 kHz Processing, sondern um Latenz. Daher sind die 96 kHz gesetzt.
Martin S. schrieb: > Ich denke eher an kleine Musikbuden, die schon lange im Geschäft sind > und vom 56k nicht wegwollen. An wen denkst Du dabei?
Martin S. schrieb: > So ist es nicht gedacht...es geht eigentlich nur um die > 56002-Kern-Kompatibilität, alles Interrupt-Zeug ist nicht drin und soll > auch nicht rein, das erledigt die Front-End-CPU per DMA. Moin Martin, verstehe ich das richtig dass du so eine Emulation anstrebst btw schon begonnen hast? Ich probiere mich gerade hieran und suche Programmierer mit Erfahrung: https://github.com/MisterTea/MAMEHub/tree/master/Sources/Emulator/src/emu/cpu/dsp56k
Thomas F. schrieb: > Lösungen z.B. mit SHARCs? Definiere bitte mal "viel FIR". Exakt. Sharc DSPs mit Visual DSP++. Gibt kaum was Besseres, abgesehen von den Construction Sets, die manche IDEs von Audio-DSPs mit on board haben. Holger B. schrieb: > aber es geht hier nicht um vermeintlichen > Qualitätsgewinn mit 96 kHz Processing, sondern um Latenz. Daher sind die > 96 kHz gesetzt. Das musst du mir mal erklären, warum bei der gesteigerten Abtastrate eine geringere Latenz auftreten soll. Martin S. schrieb: > Was hältst du vom Ansatz, ein (oder mehrere) 56k-Design(s) in ein > grösseres FPGA zu verbacken? Ich höre immer mal wieder von > 56k-ASM-Veteranen, dass sie an sowas Interesse hätten. Ich wüsste nicht, wozu es heute eine Emulation einer 25 Jahre alten Prozessorarchitektur bräuchte.
Sharky schrieb: > Ich wüsste nicht, wozu es heute eine Emulation einer 25 Jahre alten > Prozessorarchitektur bräuchte. Soetwas z.B.? Beitrag "Pseudo Kunstkopf Stereo mit DSP56002, alte Motorola Applikation"
Sharky schrieb: > Das musst du mir mal erklären, warum bei der gesteigerten Abtastrate > eine geringere Latenz auftreten soll. Die AD/DA Laufzeiten sind bei 96 kHz halbiert, das macht in unserem System 100 µs aus, was durchaus signifikant ist.
Sharky schrieb: > Martin S. schrieb: >> Was hältst du vom Ansatz, ein (oder mehrere) 56k-Design(s) in ein >> grösseres FPGA zu verbacken? Ich höre immer mal wieder von >> 56k-ASM-Veteranen, dass sie an sowas Interesse hätten. > Ich wüsste nicht, wozu es heute eine Emulation einer 25 Jahre alten > Prozessorarchitektur bräuchte. Dito. Außerdem müssten sich die meisten Anwendungen mit mehr oder weniger Aufwand auf einen der moderneren Chips wie DSP56724 portieren lassen. Holger B. schrieb: > Sharky schrieb: >> Das musst du mir mal erklären, warum bei der gesteigerten Abtastrate >> eine geringere Latenz auftreten soll. > > Die AD/DA Laufzeiten sind bei 96 kHz halbiert, das macht in unserem > System 100 µs aus, was durchaus signifikant ist. Was verstehst du hier unter "Laufzeiten"? Es müssen doch doppelt so viele samples berechnet werden. Der Wandler gibt auch doppelt so viele aus. Oder meist du Verzögerung bis zum ersten sample?
Thomas U. schrieb: > Dito. Außerdem müssten sich die meisten Anwendungen mit mehr oder > weniger Aufwand auf einen der moderneren Chips wie DSP56724 portieren > lassen. Schon, aber es gibt doch mehr Leute, die noch an dem Ding hängen, als man denkt. Scheint sogar auch hier noch den einen oder anderen Nutzer zu geben: Beitrag "Wer arbeitet noch mit der alten Motorol 56301 SW?" Und was ich halt gerne hätte, wäre ein Abbild meines alten Soundprozessors: https://web.archive.org/web/20170130163934/http://home.arcor.de/juergen.schuhmacher/chameleon.html http://www.96khz.org/htm/chameleonsynth.htm http://www.chameleon.synth.net/english/index.shtml Statt der AD-Wandler und DACs hätte meine Plattform eine Anzahl PDM und I2S-Schnittstellen, an die man entweder analog oder mit S/PDIF dran kommt. Die Bediensoftware lässt sich mit VST-Emulation sicher recht schnell nachbilden. Synthesizer gäbe es dann einige. Von manchen sogar den Code. Als Appetithappen mal das hier: https://www.chameleon.synth.net/english/skins/fahrenheit/ Unten auf der Seite sind Demosongs in MP3. Man müsste halt die komplette Coldfire Architektur und den DSP mit kapseln. Es ließe sich theoretisch sogar die Frequenz hochtreiben! Aus 48kHz mach 192kHz. Technisch wäre das machbar denke ich.
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.