Hallo, ich möchte mich näher mit DSP im Bereich Audio beschäftigen und suche eine möglichst überschaubare Plattform hierfür. Ich möchte einfache Filterfunktionen (TP, BP, Notch etc.) realisieren, also nichts sonderlich rechenintensives. Das Board sollte einen LineIn (Stereo) sowie LineOut (Stereo) und natürlich einen Codec besitzen und möglichst Fließkommaarithmetik unterstützen. Außerdem wäre die ein oder andere Datenschnittstelle nett (RS232, SPI). Ich möchte das DSP-Board später zusammen mit einem Benutzerinterfache (µC, Display, Drehgeber, Taster etc.) in ein kleines Gehäuse einbauen um es zwischen einem Empfängerausgang und Kopfhörer zu schleifen. Ich habe bereits ein DSP-Board mit einem Blackfin von Analog Devices, was ich jedoch für oversized halte. Zumal es ein Festkomma-DSP ist... Ach so, das Board sollte natürlich in Deutschland für Privatpersonen erhältlich sein:) Ich wäre sehr dankbar, wenn mir jemand Tips geben könnte. Gruß Jan
Jan schrieb: > Ich habe bereits ein DSP-Board mit einem Blackfin von Analog Devices, > was ich jedoch für oversized halte. Zumal es ein Festkomma-DSP ist... Also wenn etwas für Audio oversized ist, dann ist es Fliesskomma. Wenn du letzeres unbedingt brauchst, mach's gleich auf nem PC oder ARM, oder dann SHARC. Aber erst würde ich mir die benötigte Arithmetik genau anschauen. Die MAC-Units des Blackfin sind optimal für Audio, wenn man sie in Assembler programmiert. Allerdings kann man für 24 bit audio nicht parallel-instructionen fahren, aber bei 500 mhz wird der Chip nicht müde.
SoundScape Mixtreme 192 von Sydec mit Developer License. Hat einen 56301 drin, der direct in C prgrammierbar ist. Standard Audio Funktionen können mit Modulen zusammengeklickt werden, ohen zu prgrammieren.
Vielleicht wäre der Spinsemi FV-1 eine Möglichkeit. [Vom damaligen Alesis-Gründer Keith Barr entwickelt, leider weilt KB nicht mehr unter uns, aber das Projekt wird weiter betreut.] Ist in etlichen kleinen Mischpulten und Gitarren-Tretern verbaut. Wird über ASM programmiert, es gibt im Spinsemi-Forum gutes Codefutter und Community Talk. http://www.spinsemi.com/products.html Das Eval-Board ist leider ziemlich teuer, aber hier ist ein Elektor-Projekt, mit passendem Board und AVR-Drumherum: http://www.elektor.de/jahrgang/2010/september/digitales-multi-effektgerat.1468097.lynkx?tab=4 Der DSP ist für ~14€ (brutto) über Segor lieferbar.
Aus dem Datenblatt: "48 kHz" "128 instructions/sample clock" "1 s Reverb time" Das sollte für einfach Anwendungen wie IIR reichen. Für mehr aber auch nicht. 1) Heute ist 192kHz Standard -> Faktor4 an Rechenbedarf 2) Mehrkanalig = Faktor 8 3) 8s Hall für echten Nachklang -> Faktor 8 4) FIR-Filter mit ausreichend TAPs = 512 Instructions /sec -> Faktor 1024!
Ich benutze das TAS3208 LowCost Board von TI. 3,5 mm Stereo In/Out und SPDIF, 48bit Datenpfad,72 bit Akku, I2C controllierbar und kommt mit PurePath Lizenz für ca 120 Euro aus Forth Worth. http://www.ti.com/tool/tas3208evm-lc Hier ist mein Bassverstärker Projekt mit dem Teil: http://www.schoeldgen.de/bassalizer/index3.html Unten auf der Seite siehst du den Process Flow für den Amp.
Leider wird der TAS3208 demnächst abgekündigt. So etwas ist nicht gut für ein neues Produkt. http://www.ti.com/product/tas3208 NRND: This product is not recommended for new designs. However, the device, tool, or software continues to be in production to support existing customers. TI does not recommend using this part in a new design. TI encourages designers to consider alternative products for new designs.
K. schrieb: > 1) Heute ist 192kHz Standard -> Faktor4 an Rechenbedarf > 2) Mehrkanalig = Faktor 8 > 3) 8s Hall für echten Nachklang -> Faktor 8 > 4) FIR-Filter mit ausreichend TAPs = 512 Instructions /sec > > -> Faktor 1024! Ah ja. Abgesehen davon, dass dies meilenweit an den o.g. Erfordernissen vorbei geht... ist das doch ziemlicher Humbug. Zumindest wenn wir von Algorithmischem Hall reden, nicht von Impulsantworten. Kannst Du bitte Deine Erkenntnisse faktisch untermauern? Als jemand, der schon mehrere Jahre kommerziellen in diesem Bereich arbeitet, will mir das nicht einleuchten. Die wichtigste Erkenntnis bei algorithmischem Hall: wir haben es mit einem rekursiven Prozess zu tun. Es ist völlig schnulli, ob das 0.5s oder 2 Stunden sind (gut, nach hinten kommt Quantisierungsrauschen aufgrund Rundungsfehler mit rein...). Das einzige, was ein Hall braucht, ist schnell zugreifbarer Speicher. Den aber nur für die Hauptloop und serielle Allpässe (z.B. ältere Lexicon, 480, 960, PCM) oder aber viele kürzere für FDNs (z.B. TC). Der einzige, aktuelle, der richtig viel Speicher an Bord hat, ist der Bricasti M7. Da ist die main loop ~30sec, dazwischen eine Reihe von Allpässen. ImGrunde ein Design wie in alten Lexicons, aber auch Alesis. Wer die alten Designs von Keith Barr (R.I.P.) kennt (ex-Alesis, später Spinsemi), weiß, dass er schon bei den durchaus guten Geräten wie Midiverb III/I4 & QuadraVerb lediglich eine lange Stereo-Loop hatte, die mit tapped Allpässen gespickt war. Bei Lexicon sind häufig kleine Delays dazwischen moduliert gewesen (->aufbrechen der Resonanzen/Moden), bei Barr eher die Allpässe. Modulation ist dann eher auch die Achillesverse der alten Designs gewesen, nicht die Modelle an sich. Es gibt einige gute Beispiele für den FV-1, die zeigen, dass der sehr wohl imstande ist, ordentliche Algorithmen zu stemmen. So z.B. auch die bekannte figure-8-loop von Jon Dattoro (ex-Ensoniq, später Lexicon), die für die Plates im Lex 224 eingesetzt wird. Ursprünglich mono, wobei die Taps einen Pseudo-Stereo-Effekt erzeugen. Man kann es aber prima auf 2 main loops erweitern, und sogar ein klassisches FDN drumherum stülpen, mit lediglich 1x add und 1x mul mehr (Householder Matrix). Ein simples 8x8 FDN sollte der FV-1 auch schaffen. Pro Delayline noch 2 Allpässe rein, dann hätte man je nach Gewichtung der Taps 8-Kanal Surround. Wenn wir z.B. maximal 1 sec Samplespeicher haben, sollte das trotzdem reichen: 330m/s : 8 = 41.25m maximales Delay. Das ist schon ein ordentlich In der Praxis würde man für ein FDN ein Primzahlenverhältnis der Delays anstreben. Z.B. 2, 5, 11, 17, 23, 29, 37, 41 (= 165m -> 500ms Platzbedarf). Den Rest kann man noch für Allpässe und ggf. IIR-Filter verballern. Oft bekommt man Surround quasi 'nebenbei' umsonst geschenkt. Eigentlich immer dann, wenn man Hallalgorithmen auf Matrizenbasis aufbaut; Stichwort Feedback Delay Network (FDN) bzw. Waveguide Mesh. Zur Bandbreite: Bei allen 'legendären' Hallgeräten ist die Audio-Bandbreite immer stark begrenzt gewesen, z.B. erste Versionen des Lex 224 ~29k. Später hat man die Begrenzung in so gut wie allen Geräten beibehalten. Ein natürlicher Raum, oder sagen wir gar, ein guter Konzertsaal, hat wenig signifikanten Anteil oberhalb von 6-8k, oft ist es gar störend. Manche modernen Design betreiben gar ein Undersampling, um die Vorgänge in den alten Kisten nachzubilden. Sicher, ein TC M6000 oder größer ist bei PostPro/Scoring und Classic-Bearbeitung State of the Art, aber für den Großteil der Musikproduktion weltweit werden nach wie vor Geräte der alten Schule (eben 480 & 960) eingesetzt. Dass DAW-Projekte aktuell oft in 96k laufen (und äußerst selten in 192k!), hat nicht viel damit zu tun. Da geht's eher um das einfangen akustisch-diffizilen Materials. Höhere Sampleraten bei Effekten an sich macht nur Sinn, wenn Nichtlinearitäten erzeugt werden sollen (z.B. bei Amp Modelern, die haben i.d.R. 8x bei 44k1). Bei rekursiven Strukturen wie Delay/Chorus/Flanger/Hall ist die Wortbreite entscheidend, vor allem, wenn nicht fixed-point.
Sascha schrieb: > Audio-Bandbreite immer stark > begrenzt gewesen, z.B. erste Versionen des Lex 224 ~29k Hups, Samplerate, nicht Bandbreite. genauer: 29.761kHz Samplerate. Das 960L kann auch 96k, aber da geht es ehr um die digitale Einbindung in DAWs, nicht die Algorithmen per se.
@Sascha: Dass Du in dem Bereich tätig bist, würde ich angesichts Deines Wissens nicht bestreiten, dennoch sehe ich da Kritikpunkte! Du scheinst eher im Consumerbereich aktiv zu sein, denn : >Dass DAW-Projekte aktuell oft in 96k laufen (und äußerst selten in >192k!), Da müsste man diskutieren, was DAW-Projekte sind. Ich produziere im Studio, mach Mastering und entwickle auch Algorithmen für namhafte Firmen und kann Dir versichern, dass heute immer mehr in 192k gemacht wird - insbesondere Samplerprojekte im Bereich Orchester. Aber: >Da geht's eher um das einfangen akustisch-diffizilen Materials. Das eher nein. Gesampelt wird mit 96k, weil die meisten Wandler die 192k eh nur durch Reduktion des Oversampling s auf Faktor 2 generieren, was also aus analoger Sicht nichts bringt und nur den Datenstrom verdoppelt, was bei der Aufnahme die Kanalzahl halbiert! > Höhere Sampleraten bei Effekten an sich macht nur Sinn, wenn > Nichtlinearitäten erzeugt werden sollen (z.B. bei Amp Modelern, Wo bitte bringt eine erhöhte Samplerate hier Vorteile? Dem Prinzip nach haben die hohen Samplerate im Wesentlichen DEN Vorteil, dass mit weicheren Filtern gearbeitet werden kann und man ein feineres Noiseshaping applizieren kann, mit dem z.B. Algos gesmoothed werden können, um, die letzten Bits herauszukitzeln. Beim Erzeugen von Nichtlinearitäten sind soviel Zufälle und Artefakte im Boot, dass es genau dort sicher nicht auf Präzision von Filterkennliniean ankommen wird. > Bei rekursiven Strukturen wie Delay/Chorus/Flanger/Hall Inwiefern ist ein Chorus rekursiv? oder ein Flange? ??? Auch beim Hall ist es ein Trugschluss, man könne als algorithmisch rekursiv lösen, und kurze immer wiederkehrende Echos wiederverwenden. Man kommt da sehr schnell an dieselben Grenzen, wie bei den Codierverfahren, wo immer mehr Ähnlichkeiten auftreten. Rechnet man sich aus, dass eine erste Echoverzögerung in einer 20m langen Kirche, die man in Realzeit emultieren will, 130ms bis zur Reflektion dauert, dann kommt man bei 192kHz schon auf 25.000 samples. Die nun einfach wie andere dazwischenliegende Echos immer wieder abzuspielen, führt vielleicht zu einem lustigen Reflexionsszenario, hat aber mit der Realität wenig zu tun. >Lexicon Deren bester Hall ist der, wo sie die Kurzreflektionen, die das Gehör zu Ermittlung der RAumgrösse nutzt, zufällig kommen lassen und dies genau deshalb, weil sich das Gehör massivst an wiederkehrenden Mustern stört. Für einen grossen deutschen Hersteller von Live- und Studiopulten habe ich daher einen Hallgenerator entwickelt, der 16 generische Reflekionen je Raumbegrenzung (>6 ... <18) berechnen und in Anrechnung der luftabhängigen Dämpfung über die Distanz bestimmen kann. Dazu sind Wegstrecken von maximal 1023m und bis zu 255 Einzelreflektionen zu verfolgen. Die 16x255 "Strahlen" müssen parallel je Sample gerechnet werden, hinzukommen die "Equalizer", die an den Wänden auftreten. Die RAM-Grösse beträgt für alle Signalquellen >16GB. Die beteiligten DSPs rechen auch nur das! Eingesetzt wird es z.B. für Nachvertonung und Bearbeitung von Synchronaufnahmen , wo Sprecher in der Reflektionsfreien Kabine sprechen, der Tontechniker sie aber in den realen Raum rückversetzen knan.
K.U. schrieb: >> Bei rekursiven Strukturen wie Delay/Chorus/Flanger/Hall > Inwiefern ist ein Chorus rekursiv? oder ein Flange? ??? Das ist nicht Dein Ernst, oder??? Wie bitteschön würdest Du Chorus und Flanging algorithmisch lösen, wenn nicht durch (rekursive) Delay Lines? Klar, es gibt Erbsenzähler, die behaupten, in beide Typen gehöre kein Feedback. Aber solche Leute denken nicht musikalisch, und vor allem nicht, wie sich Musikequipment und ihr Einsatz im Laufe der letzten Jahrzehnte entwickelt hat. Kein Künstler ist gleich, insofern auch nicht der Einsatzzweck. Wenn Du Erstreflexionen via sowas wie Mirror Image / Raytracing realisierst, ist das ein valider Ansatz. Kommerzielle Hallgeräte benutzen abseits davon für ERs ja oft auch Impulsantworten, einfach weil das Empfinden von Raumgröße, die eigene Lokalisaion in einem virtuellen, und die Ortung von Schallquellen algorithmisch schwer zu bewerkstelligen ist. Zumindest nicht bei Aufgaben, die möglichst exakt sein sollen. Ich rede aber von Musikproduktion, und das hat nichts mit 'Consumer' zu tun. Schau in Dein CD-Regal, zieh irgendwas aus den 80ern bis Mitte 90ern raus, die Wahrscheinlichkeit ist groß, dass z.B. ein Lexicon 480 (das mit dem 'Taschenrechner') dran beteiligt war. Das Teil ist nach heutigen Maßstäben ein Witz, tatsächlich wurden aber unvergessliche Welthits damit kreiert und somit Millionen von Menschen viel Freude bereitet. Allerin dafür gebührt Davis Griesinger ein Denkmal. Angesagt der heutigen technischen Möglichkeiten mag das Kokolores sein, aber man fragt sich auch, warum immer noch Menschen anderen Menschen Spaß bereiten, indem sie 6 Stahlsaiten auf einem Stück Holz bedienen. Apropos: >> Höhere Sampleraten bei Effekten an sich macht nur Sinn, wenn >> Nichtlinearitäten erzeugt werden sollen (z.B. bei Amp Modelern, > Wo bitte bringt eine erhöhte Samplerate hier Vorteile? Man merkt, du kommst da nicht aus der Musikecke... nun gut, starte mal den Selbstversuch: nimm einen Waveshaper Deiner Wahl, meinetwegen tanh(x), und jage bei 44k einen Sinus Sweep durch, im (für z.B. Gitarren) relevanten Frequenzbereich bis, sagen wir, 5k. Gain: vielleicht praxisnahe 60dB über Nominal (ist für Metal z.B. völlig normal). Und dann wiederhole das mal mit 8x oder mehr. Vernünftige Amp Modeler haben natürlich Brickwall Filter am Eingang, nebst weiteren Tiefpässen zwischen den Stufen (um z.B. die Miller-Kapazität zu simulieren). Aber das allein reicht nicht, da die generierten Obertöne einfach zu massiv im noch hörbaren Bereich sind bzw. ja 'auf dem Weg' erzeugt werden. Zum Nachvollziehen empfehle ich das Studium eines typischen, 'hochgezüchteten' Gitarrenamps, z.B. einen mit 5 bis 7 Gainstufen (Mesa/Boogie, Peavey, Engl o.ä.). Ich könnte noch einiges dazu sagen, aber ich will den Thread nicht hijacken. Letztlich geht es um einfache, robuste DSP-Themen, und da halte ich den Spinsemi FV-1 für eine runde Sache.
Sascha schrieb: > Man merkt, du kommst da nicht aus der Musikecke... Sagen wir, ich komme nicht aus der Ecke Gitarristen, die mit ihren Amps allesmögliche und esotherische veranstalten und dort Dinge hören, die technisch nicht begründbar sind. Ich bin sicher, dass das nächste Argument der warme klang ist :-) > Schau in Dein CD-Regal, zieh irgendwas aus den 80ern bis Mitte > 90ern raus, Schau in Dein Regal und ziehe was aus den späten 90ern heraus. Einiges, was von Korg-Synths (speziell Rack-Synths) ertönt, stammt aus von mir mitentwickelten EPROM-Sounds und einige CDs, die du sicher kennst, wurden von unserem damaligen Studio gemastert. >nicht durch (rekursive) Delay Lines? Du scheinst das Wort "rekursiv" anders zu verwenden, als es die Mathematiker definiert haben. Beim Hall z.B. ist es maximal eine Iteration und ich sehe bei der Berechung von Choruseffekten keines von beiden. Ich lasse mich aber gerne eines Besseren belehren: >aber ich will den Thread nicht hijacken. Beschreibe doch mal, wie du Rekursion bei dem von dir empfohlenen Chip einsetzen würdest. Das würde auch zum Thema passen. > Kommerzielle Hallgeräte > benutzen abseits davon für ERs ja oft auch Impulsantworten Die statisch sind und damit nicht eingestellt werden können. Mein Hallmodell ist in Echtzeit parametrierbar, man kann z.B. eine Schalltquelle virutell gegen die Wand zufahren lassen. Ferner kranken Impulsantworten an der Mikrofonaufnahmetechnik: Alle Reflektionen werden mit der Kennlinie der Mikrofone aufgefasst und auch wenn man reine Diffussfeldaufnahmen mit entzerrten Kugeln tätigt, haben diese noch eine Präferenz in der Hauptachse und generell stimmt die Chrakteristik nicht mit dem überein, was das Ohr mit Reflektionen verantaltet (von der Seite heller, von hinten dunkler) Wenn man das künstlich berechnet, kann man z.B. unterscheiden, ob man für LS-Stereo oder binaurale Ohrsignale (Kopfhörer) abmischen möchte und man kann die Effekte der Kanaltrennung durch den Kopf erzeugen / eliminieren, die dafür verantwortlich sind, dass die Elongation beim Pegelstereo(panning) und auch Phasenstereo stark frequenzabhängig ist. So z.B. gelingt es, elementare, modulare Wellen zu erzeugen, die phasen- und pegelrichtig aus der richtigen Richtung kommen und nach Massgabe einer virtuellen Aufnahmekennlinie (AB, ORTF, binaual headphone) auf z.B. 8 Lautsprecher verteilt werden können.
K.U. schrieb: >>aber ich will den Thread nicht hijacken. > Beschreibe doch mal, wie du Rekursion bei dem von dir empfohlenen Chip > einsetzen würdest. Das würde auch zum Thema passen. Falls Du mit Rekursion die mathematische Definition auf Funktionsbasis meinst: Nein. Nennen wir es mal schlicht 'Feedback'. Nehmen wir mal ein 4x4 FDN mit Householder-Matrix. Im einfachsten Fall, mono in, mono out: (frei von der Leber, kann fehlerhaft sein)
1 | /*
|
2 | fb: feedback factor (->RT60)
|
3 | nDelayLines: 4
|
4 | */
|
5 | |
6 | float distance[4] = {3, 11, 21, 37}; // whatever... in meter |
7 | |
8 | for (j=0; j<nDelayLines; j++) |
9 | {
|
10 | ringbuffer.setSize ((distance[j] / 330.f) * sampleRate); |
11 | }
|
12 | |
13 | float dlyout = 0; |
14 | float negfb = (-2 / nDelayLines) * fb; |
15 | |
16 | for (i=0; i<iBufSize; i++) |
17 | {
|
18 | float dlyin = input + negfb * last_out; |
19 | for (j=0; j<nDelayLines; j++) |
20 | {
|
21 | float temp = ringbuffer[j].read (); |
22 | dlyout += temp; |
23 | |
24 | float dlyin = in + temp * fb; |
25 | ringbuffer[j].write (dlyin); |
26 | }
|
27 | |
28 | last_out = dlyout; |
29 | }
|
ringbuffer ist in meinem Fall eine Klasse, die halt einen Ringpuffer implementiert. Sollte also klar sein. Im Prinzip ist das ein Schröder-Moorer-Hall, mit 4 parallelen Delaylines. Zu einem FDN mit Householder wird es lediglich durch das globale (negative) Feedback. Je nachdem, wie die 4 Delays verteilt sind, wird aus den einzelnen Echos schnell eine komplexe Hallfahne. Bei dlyin könnte man zum weiteren verschmieren der Inpulsantwort noch pro delayline einen allpass davorhängen. Also schlicht ein weiterer Ringpuffer, mit feed-forward und feed-back-Zweig. Koeffizient versuchsweise 0.5..0.6. Die Algorithmen von Barr sind eher in der Art:
1 | Kanal 1: |
2 | input1 + fb * output2->allpass 1_1->delay1_1->ap2_1->dly2_1->ap3_1->dly3_1->output1 |
3 | |
4 | Kanal 2: |
5 | input2 + fb * output1->allpass 1_2->delay1_2->ap2_2->dly2_2->ap3_2->dly3_2->output2 |
Also zwei lange loops über Kreuz. Der Ausgang wird nicht nur an 'output', sondern auch an den Allpässen und Delays abgenommen. Also wie ein Tap Delay. Der Vorteil von langen Loops ist ja, dass man für die Hallfahne eine Envelope kreieren kann. Und das ganze mit minimalem Aufwand. Gerne kannst Du posten, wie Du Source/Image-Rendering von Erstreflexionen in die paar Operationen bekommst ;) ASM-Code zu Hall, Modulation und auch zu Filtern findet sich übrigens massenweise im Spinsemi-Forum.
Helmut S. schrieb: > NRND: This product is not recommended for new designs. Hmm, hatte ich gar nicht gelesen. Vllt. hat TI sich mit der Übernahme von NatSemi übernommen ? Schade, finde die Kiste recht nett und macht brav ihren Job, live und im Proberaum.
Zwischenfrage: Wofür benötigt man die vielen Allpässe? Sind das Phasenschieber?
Michel schrieb: > Zwischenfrage: Wofür benötigt man die vielen Allpässe? Sind das > Phasenschieber? https://ccrma.stanford.edu/~jos/Reverb/Reverb.html http://www.music.mcgill.ca/~gary/307/week3/reverb.html Grundsätzlich geht's um Impulsverbreiterung, Dekorrelation. Aber z.T. auch Dispersion. In der Natur kommen Allpassfilter so nicht vor, deswegen sind Verschmierungseffekte via Allpass nicht naturgetreu. Aber sie sind billig zu haben und mit zusätzlicher Filterung (oder einbetten eines Filters in den Allpass selber, wobei er dann nicht mehr 'all-pass' ist...) lässt sich die Dichte bzw. Dispersion erhöhen. Einige Modelle mit Kammfiltern sind von sich aus 'all-pass'. Das FDN, das ich oben vorgeschlagen habe, verhält sich auch so, zumindest entlang der Diagonalen der Matrix. Interessant sind Allpässe höherer Ordnung für reine Dispersionsfilter, wie man sie z.B. für Federhall (Hallspirale bei Gitarren- oder Keyboardverstärkern) braucht, zumindest wenn es authentisch sein soll, mit dem charmanten 'plätschern' und 'pfiuuuu' auf dem Attack. Das geht, wenn man sich überlegt, wie Schall sich in einer Feder, bestehend aus einem Medium wie Stahl, ausbreitet: die hohen Töne kommen zuerst an, die Tiefen ziehen nach. Durch Reflexionseffekte und Absorption 'auf dem Weg' bzw. an den Enden wird das ganze aber akustisch sehr komplex und interessant. Ein Chirp einer Hallspirale sieht ziemlich klasse aus, und man hört es auch. Ziemlich geiles Paper hierzu: http://www.dafx.ca/proceedings/papers/p_013.pdf (Jonathan Abel ist einer der beiden UAD-'Doktoren'. UAD sind nicht zuletzt deshalb so erfolgreich, weil sie durch Agreement mit Standford deren Forschungsergebnisse als erste kommerziell verwenden dürfen. Das Paper z.B. ist erst nach Release der EMT250-Plate-Emulation veröffentlicht worden.) Ein Allpass verzögert ja frequenzabhängig, deshalb der Effekt. In Räumen tritt sowas extremes eher nicht auf, da haben wir es eher mit Phänomenen wie den Moden zu tun (Druckminima/-maxima), die erfordern eine andere Betrachtung. Aber mit Allpäsen kann man generell schon eine Menge machen. Vor allem sollte man sich überlegen, wo eigentlich überall Allpässe drin sind, ohne das sie Absicht waren. Viele Effekte der analogen Audiotechnik und auch ein Teil der Mythen gehen auf Allpasseffekte zurück, seien es Wellenformen analoger Synthesizer oder der 'fette' Sound bestimmter Dynamikprozessoren. Die Leute bestimmen immer gerne nur den Amplitudengang und den Klirrfaktor, dabei liegt das Geheimnis oft im Phasengang. Aber es ist vom Verständnis schwieriger zu packen.
UAd ist ein gutes Stichwort. Da wird recht genau beschrieben, wie sie Chorus und Flange einordnen. http://www.uaudio.com/blog/modulation-effects-basics/ Ich habe seinerzeit was mit der AUD1 gemacht, war aber zu schwachbrüstig und ich bin zu Sydec gewechselt. Die haben mir auch Devel Kit und Libs offeriert - keine Ahnung, bo sie das heute auch noch machen. Um mal zurückzukommen auf die Frage des OP: >Re: DSP-Plattform für Audio Die UAD2 sieht technisch gut aus: http://www.uaudio.com/uad-plug-ins/pcie/uad-2-quad.html "Günstig" sieht aber anders aus :-) Wobei die Plattform ihrGeld wert wäre, wenn man sie selber bedienen könnte, denke ich aber nicht, dass die open sind.
K.Unger schrieb: > Wobei die Plattform ihrGeld wert wäre, wenn man sie selber bedienen > könnte, denke ich aber nicht, dass die open sind. Nein, so blöd sind die nicht. Die Karten sind ihre eigenen Dongles, ihr Investitionsschutz.
Servus, Warum nimmst Du keine DSPIC's? Da gibt es jetzt welche mit 70 mip's und das macht bei 16bit und fs=96kHz 730 Takte zur Berechnung von nur einem Sample. und bei 62,5 kHz 1120 Rechenoperationen. Da gibt es einen Typ sogar in DIP. Warum DSPIC? weil der nur 7 € oder so kostet und ein Programmiergerät 30€. Also ich programmiere darauf momentan einen va-Synthesizer. Und die sind ganz gut beherschbar und haben 16 kB Ram und gute MAC-Befehle. Natürlich müsstest Du in ASM schreiben. Aber ich muß auch zugeben das eine PULSWELLE bei nur 62,5 kHz fs nur bis 300 Hz gut klingt ,denn dann kommt massiv Jitter. Aber sinus und Sägezahn und Ringmodulation und LFO's im am und FM betrieb sind kein Problem. Schau dir die Dinger mal an denn für wenig geld gibt's gure Rechenleistung. mfg
Maik Werner schrieb: > PULSWELLE bei nur 62,5 kHz Was meinst du mit Pulswelle? Gibst Du 1-Bit PWM aus? Wenn Du wenigstens 35kHz an 16 Bit Daten berechnen kannst, bekommst Du auch mit einem mittelmässigen AA-Filter nach einem DAC einen ordentlichen Sinus bis 15kHz hin, mehr hörst du eh nicht, bzw ist in den Musiksignalen auch nicht drin. Maik Werner schrieb: > 62,5 kHz 1120 Rechenoperationen Macht dann 1600 Inst / sample. Ich habe mal einen Synthie gebaut, der mit etwa 1500 Befehlen in ASM auskam. Er konnte 1 Kanal :-) Schon cool, wo die heutigen Chips angekommen sind.
also die Pulswelle erzeuge ich durch den DPW-Algorithmus.ich subtraier zwei phasenverschobene Sägezähne miteinander. Die Sägezähne hören sich sauber an, aber die Pulswelle klingt halt ab 300 Hz verzerrt. Das Phasenregister sind die oberen 16 bit eines 21 Bit Counters. Dann quadrier ich den Counter und ziehe den alten vom neuen ab. so bekomme ich meine Sägezähne. Ach ja das ganze fäuft halt auf 40 Mips dspic's .DSPIC33fj64gp802 Ja aber der Thred hat ja eigentlich ein anderes Thema, ich weis. Hättest Du da einen Tip für mich zwecks Pulswelle?
Für deine Anforderungen ist das http://ch.farnell.com/texas-instruments/tmdx5505ezdsp/entwicklungsbord-ezdsp-usb-stick/dp/1796123 ideal... Hab selbst eines. Gruss
Maik Werner schrieb: > Die Sägezähne hören sich > sauber an, aber die Pulswelle klingt halt ab 300 Hz verzerrt. Das werden die Spiegelfrequenzen sein. Warum machst Du das so kompliziert? DWP war nötig, als man noch keine schnellen Zähler und DACs hatte, sondern mit elektronischen Rampen und Vergleichern arbeiten musste. Wenn Du das so machen willst, muss Du ein bandbegrenztes Signal nehmen,
Die Sägezähne sind bandbegrenzt der Puls leider eben nicht mehr. Wie kann ich das in 60 Takten schaffen, son genügend bandbegrenzten Puls zu erzeugen. PS der Prozie ist ein 16 bitter DSPIC...?
IIR-Filter: FilterWertNeu := FilterWertAlt * 0,9 + NeuerWert * 0,1 (z.B). Das für beide "Sägezähne". Aber nochmal: Du kriegst auf diese Weise keine besseren Pulse, als mit digitalem ON, OFF.
Klausi ich habs begriffen. Und danke "MB" für deinen Link. Da muß halt einfach andere Hardware her! danke
@MB Danke für den Link, dass Teil gefällt mir sehr gut. Werde es mal damit probieren, zumal es bezahlbar ist.
Leider rechnet dieser DSP nur mit 16 Bit, das ist für Audio etwas wenig.
Andreas Schwarz schrieb: > Leider rechnet dieser DSP nur mit 16 Bit, das ist für Audio etwas wenig. Das ist für Audio sogar etwas arg wenig. Will man 16 Bit erhalten, muss man man Rundungen wenigstens 16.5 Bit = 17 berechnen und mitführen, den headroom optimal halten und dithern. 17 Bit breite Berechnungen erfordenr mittendrin aber bis zu 35 Bit Vektorbreite. Mit etwas mehr Bequemlichkeit (kein dithern des Datenstrom und normierter headroom) braucht man 17+(Faktor 10 = 4) + ca 3-4 Bit = 24 Bit. Daher haben typische Audio DSPs eher 24 Bit und arbeiten intern mit 48 Bit Vektoren. Für die 24 Bit Plattformen (moderne ADCs) hat man seit Jahren 56+ Bit intern in den Digitalpulten (28x2). Aktuelle DSPs in Audio-Systemen arbeiten mit mindestens 32 Bit und der Einfachheit halber mit 64 Bit breiten Audio-Datenbussen für Stereo.
J. S. schrieb: > Aktuelle DSPs in Audio-Systemen arbeiten mit mindestens 32 Bit Meinst Du spezielle Audio-DSPs oder solche für allgemeine Aufgaben, die fürs Audio selektiert wurden?
Hallo zäme, der interessehalber: Was für dsp´s sind denn das? Sind die Blackfins nicht auch, mit einer 32 bit CPU und mit 2x Mac-Unit a 16 bit, ausreichend für Audio? Viele Grüße
Jo also icj lese da auch immer bei der TI C5000 Serie igendwas von 16 Bit oder so. Ja und noch was ,bei dem DSPIC muß man halt die ganze Klangformung in der DSP-Einheit berechnen bei 40 bit und Zwischenergebnisse ussm Accu als 32 bit rauskriegen und zwischenspeichern.
Die C55xx von TI haben im Datenblatt folgendes stehen : The C55x CPU provides two multiply-accumulate (MAC) units, each capable of 17-bit x 17-bit multiplication and a 32-bit add in a single cycle. A central 40-bit arithmetic/logic unit (ALU) is supported by an additional 16-bit ALU.
Die ganz C55xx Familie hat doch niemand für allgemeine Audioanwendungen verwendet sondern nur für Sprache da man dort gerade so mit 16bit hinkommt. Arbeiten mit doppelter Genauigkeit ist doch mit diesem DSP eine Qual und es zieht die Ausführungsgeschwindigkeit um Faktor 5 herunter.
Klausi schrieb: > Hallo zäme, der interessehalber: > Was für dsp´s sind denn das? > > Sind die Blackfins nicht auch, mit einer 32 bit CPU und mit 2x Mac-Unit > a 16 bit, ausreichend für Audio? > Kommt auf deine Anforderungen an. Wenn Du nicht gleich 32 Kanäle parallel in hoher Qualität in 24 bit FIR-filtern musst. geht das schon. Ansonsten stellt sich aber dasselbe Problem wie bei den TI 16bit-DSPs, dass ein 32-Bit-MAC nich als Parallel-Instruktion geht. Für 24 Bit kommen noch Shift-Operationen hinzu. Bei 600 MHz stört das gegenüber einem ollen 56k wenig, aber dedizierte Audio-DSPs sind da einfach flotter und genauer (und wenn man soft-Rundungs-Logik will, dauerts wieder länger). Allerdings würde ich heutzutage die "dumme" Verarbeitung für High-End-Audio sowieso in ein FPGA auslagern, der Blackfin bringt mit uclinux mehr an komplexer Performance. Grüsse, - Strubi
Strubi schrieb: > Allerdings würde ich heutzutage die "dumme" Verarbeitung > für High-End-Audio sowieso in ein FPGA auslagern, Erzähle das mal den Kunden, die voll auf der DSP-Linie schweben :-) Aber im Ernst: DSPs sind halt einfacher zu programmieren und wenn die Compiler einigermassen was taugen, ist der Code auch leicht skalierbar zu halten und zu portieren und auch zu testen - das muss man schon sagen. Vom rein technischen her, sind FPGAs aber das Mittel der Wahl insbesondere, wenn viele Kanäle zu bearbeiten sind und echtparallele pipeline-Strukturen verwendet werden können.
Hi, also, was wäre dann ein guter Einstieg in die FPGA-Welt für Audio? Altera Cyclon IV Eval-Board und einen Nios Kern im FPGA als Controller benutzen? Könnt ihr was Empfehlen? Viele Grüße
The FV-1 DSP unit is available as a kit called eTap2hw designed by me. The structure of the design is stereo in/out but mostly used for guitar. I've also designed 7 echo emulations for this unit. All as a non-commercial activity so kit cost is around 65 Euro's available from a dutch web shop. Programming can be done through a PICkit2 programmer if required. Piet www.echotapper.nl
Thomas schrieb: > SoundScape Mixtreme 192 von Sydec mit Developer License. Hat einen 56301 > > drin, der direct in C prgrammierbar ist. Standard Audio Funktionen > > können mit Modulen zusammengeklickt werden, ohen zu prgrammieren. Machst du was damit? Soweit mir bekannt, ist die Karte veraltet, da nur noch für Win98/XP betreibbar. Zudem ist Sydec wohl zu SSL diffundiert.
Jürgen S. schrieb: > Vom rein technischen her, sind FPGAs aber das Mittel der Wahl > insbesondere, wenn viele Kanäle zu bearbeiten sind und echtparallele > pipeline-Strukturen verwendet werden können. Warum bauen dann Firmen wie SSL und UAD ihre Geräte auf DSP-Basis? Strubi schrieb: > die "dumme" Verarbeitung > für High-End-Audio sowieso in ein FPGA auslagern, der Blackfin bringt > mit uclinux mehr an komplexer Performance. Den Satz habe ich nicht gepeilt. Was genau soll ins FPGA und warum, wenn doch der Blackfin die Performance bringt, wie Du schreibst. Oder habe ich da was Falsch verstanden?
Das Posting ist bisschen veraltet...aber gut. Thomas Werner schrieb: > Jürgen S. schrieb: >> Vom rein technischen her, sind FPGAs aber das Mittel der Wahl >> insbesondere, wenn viele Kanäle zu bearbeiten sind und echtparallele >> pipeline-Strukturen verwendet werden können. > > Warum bauen dann Firmen wie SSL und UAD ihre Geräte auf DSP-Basis? > Die meisten High-End'er arbeiten sehr konservativ, da ist auch nix falsch dran. Drum findet man oft noch die `alte Schwarte´ in Form eines 56k-DSP-Derivats in den Geräten. Aber wenns Multichannel und billig sein soll, lohnt sich ein FPGA allemal, wenn du darin 16 oder mehr DSP-Kerne unterbringen kannst. Brauchst halt einen Spezialisten, die dünn gesäht sind. > > Strubi schrieb: >> die "dumme" Verarbeitung >> für High-End-Audio sowieso in ein FPGA auslagern, der Blackfin bringt >> mit uclinux mehr an komplexer Performance. > Den Satz habe ich nicht gepeilt. Was genau soll ins FPGA und warum, wenn > doch der Blackfin die Performance bringt, wie Du schreibst. > > Oder habe ich da was Falsch verstanden? Soweit ich das beurteilen kann, bringt ein Blackfin wegen seiner cleveren Cache-Architektur mehr als Top-Level-Controller, der nur noch Daten rumschiebt (über Netzwerk, etc.) und Userinteraktion regelt. Bei hohen Sampleraten, vielen Kanälen und 32 bit bremst das System u.U. zu sehr aus, deswegen macht es Sinn, Sound-Arithmetik und Systemsteuerung komplett zu trennen (ist ja in den meisten stage-fähigen Synthesizern so gelöst mit unterschiedlichen Chips). Es macht z.B. keinen grossen Sinn, eine generische CPU mit programmiertechnisch recht stupiden FIR-ops zu belasten, deswegen nahm man typischerweise auch bislang DSPs dafür. Nur, dass aus Gründen der Kosten und Verfügbarkeit ev. die klassichen DSPs allmählich durch FPGA-technik ersetzt werden. Schwierig ist eben immer die Abschätzung der Schwelle, ab wann sich die aufwändigere Entwicklung gegenüber der klassischen DSP-Entw. lohnt.
Audiorüpel schrieb: > Nur, dass aus Gründen der Kosten und Verfügbarkeit ev. die > klassichen DSPs allmählich durch FPGA-technik ersetzt werden. Hättest Du ein Beispiel dafür? Oder nur Vermutung?
Moin, der Thread ist ziemlich veraltet, aber ich sehe das ähnlich. Beispiele von der Migration DSP->FPGA könnte ich ansich anführen, aber ob das den Kunden gefiele.. Ich nehme allerdings wahr, dass im Audiobereich immer noch sehr konservativ gearbeitet wird, d.h. nur wenige auf FPGAs setzen. Hat sicher auch damit zu tun, dass die FPGA-Entwicklung nicht von allzuvielen bedient wird, und Audiofirmen wegen generell nicht gerne an Spezialisten outsourcen. In der Bildverarbeitung (eher meine Spielwiese), geht der Trend schon lange in Richtung Vorverarbeitung. Habe hier so eine Bastelplattform mit DSP und FPGA, es macht schon einen Heidenspass, Algorithmen vom DSP in die Logik zu verfrachten. Am DSP kann man sicherlich erst mal viel lernen, im FPGA dann optimieren. Das Problem ist, wenn man gute Fixkommarithmetik machen will, man mit einem üblichen Prozessor mit Rundungs-Checks etc. die Sache verlangsamt und mit einem 16-Bit-DSP zwar gute Rundungs-Optionen, aber miese Bittiefe für Audio hat. Gegen das FPGA spricht ansich der u.U. höhere Entwicklungsaufwand, aber dafür wiederum: - Simulationsmöglichkeiten - Stabilität - Flexibilität - Geschwindigkeit So weit meine Meinung dazu. Grüsse, - Strubi
Die Simulationsfähigkeit und Flexibilität würde ich bei DSPs aber höher einstufen, oder?
Naja, für die meisten DSPs gibts schon Simulatoren, aber die best-angepasste und effizienteste Arithmetik mit fast beliebiger Bitbreite zu implementieren ist für mich eher ein FPGA-Job. Ich habe das selber mal getestet, und die Entwicklung bei Pipeline-optimiertem Assembler-Arithmetik auf dem Blackfin mit dem "Nachbau" der DSP-ALU im FPGA verglichen. Die saubere Simulation und Verifikation auf der FPGA ist schneller vom Tisch als bei der CPU, das Prototyping des Algorithmus lohnt sich aber ev. auf dem DSP eher, aber nur, solange es nicht optimiert werden muss. In den DSP kann ich nicht oder nur bedingt in die Pipeline schauen, und bin auf den Goodwill der Chip-Designer angewiesen, auf Bug-Reports zu antworten. Das kann schon mal ein Vierteljahr dauern... Wieso sollte ein DSP flexibler sein?
Ich weiss nicht, ob man das, was in der Microcontroller-Welt als pipelining bezeichnet wird, mit calc-pipelines vergleichen kann, wie sie in FPGA realisiert werden (können). Bei CPUs sind das doch mehr oder weniger Schätzmethoden, die mögliche Verlaufspfade konkurrent antizipieren, um Berechungen vorauszuahnen. Bei FPGAs habe ich ein fest verdrahtete Verarbeitungskette, wo ständig jedes Element etwas tut und zwar das Richtige und einzig Nötige. Multithreading in CPUs steht auf einem anderen Blatt. Strubi schrieb: > Die saubere Simulation und > Verifikation auf der FPGA ist schneller vom Tisch als bei der CPU Finde ich jetzt überraschend. Zahlen?
Jürgen Schuhmacher schrieb: >> Die saubere Simulation und >> Verifikation auf der FPGA ist schneller vom Tisch als bei der CPU > Finde ich jetzt überraschend. Zahlen? Zahlen kann ich nicht raushauen, aber in manchen Fällen muss ich bis ins letzte Bit beweisen können, dass die Berechnung und Rundung stimmt und auf den Takt genau rausgeht. Das ist beim DSP nicht 100% zu garantieren, da u.U. Exceptions auftreten können. Zudem bekommt man die Logic-akkuraten Simulationsmodelle der üblichen Verdächtigen nicht in die Finger und muss dem Hersteller einfach glauben, dass die ALU keinen Bug hat. Selbe Glaubensfrage bei den funktionalen Simulatoren. Ist aber wohl im Audio-Bereich nicht so das Thema...
Das müsste man aber doch messtechnisch belegen können, dass ein Signal korrekt prozessiert wird? Deterministische Daten aus MATLAB einspeisen und die vorberechneten Ergebnisse mit den Messungen vergleichen.
Strubi schrieb: > Naja, für die meisten DSPs gibts schon Simulatoren, aber die > best-angepasste und effizienteste Arithmetik mit fast beliebiger > Bitbreite zu implementieren ist für mich eher ein FPGA-Job. Ok, wenn die Bitbreite stark vom Standard des DSP abweicht, mag das sein. Aber mit zwei Instructions bin ich auch beim 32Bit-DSP mit 64 Bit dabei und wo braucht man schon mehr ?
Thomas Werner schrieb: > Aber mit zwei Instructions bin ich auch beim 32Bit-DSP mit 64 Bit > dabei und wo braucht man schon mehr ? Für die reine Audio-Bearbeitung werden in Pulten regelmässig mit 48 Bit gerechnet, wegen 24 im Quadrat. Zur einfachen Fehlervermeidung nimmt man etwas mehr, um die Genauigkeit ohne detaillierte Rundungsbetrachtung zu erhalten. Grundsätzlich kommt man mit 64 Bit prima hin, absolut. Es sind aber nicht nur 2 instructions, also das Doppelte, wenn man 64 Bit mit 32 Bit emulieren möchte und auch der Faktor 2 kann schon weh tun, wenn man FIR-Filter berechnen will. Bei aktuell typischen 192kHz Abtastfrequenz reicht ein 200 MHz getaktetes FPGA gerade gut aus, um ein 1024-TAP-Filter voll sequenziell zu berechnen, das Ergebnis zu speichern und mit Kanalsummen zu verrechnen, da 1041 Takte vorliegen. Man bekommt also den Filterwert in Echtzeit (bezogen auf die Samplerate). Mit einem tyischen MUL in einem S6 kann man das auch sehr platzsparend realisieren und hat bei 24 Bit Daten sogar 18 Bit Koeffizienten, was sehr gut ausreicht. Das wird in einem DSP etwas haarig. Noch schwerer wiegen Echtzeit-Spektrumanalysen und -faltungen. Auch die sind im FPGA noch unterhalb der Samplegrenze zu machen, wenn auch mit einer etwas grösseren pipeline. Im DSP gibt es da keine Chance.
Jürgen S. schrieb: > Man bekommt also den Filterwert in > Echtzeit (bezogen auf die Samplerate). Mit einem tyischen MUL in einem > S6 kann man das auch sehr platzsparend realisieren und hat bei 24 Bit > Daten sogar 18 Bit Koeffizienten, was sehr gut ausreicht. Das wird in > einem DSP etwas haarig. Käme auf die Anforderungen an. > Noch schwerer wiegen Echtzeit-Spektrumanalysen und -faltungen. Bei einem Audio-Spektrum-Analysator reicht eine updaterate von 16ms, weil die TFT-Bildschirme eh nicht mehr darstellen können. Ein 100MHz DSP bekommt da ganz bequem auf > 1Mio instructions. Das richt dick für eine 128k FFT.
Die Frage ist, was der jeweilige Nutzer als "Echtzeit" definiert. Wenn es wirklich nur darum geht, ein Spektrum so schnell zu berechnen, dass man es auf 60Hz update rate darstellen kann, hat er natürlich Zeit ohne Ende. Wenn die FFT-berechneten Audio-Daten aber mit voller Datenrate gefaltet werden müssen, um z.B. eine response-basiertes Echo zu berechnen, brauchst Du einen Durchsatz von wenigstens Samplefrequenz x Filterlänge je Kanal. Für 2 Kanalechos ohne echte Lokalisation, also nur der Repräsentierung einer Reflexion je Impuls, geht das schon für 1 Kanal und dee derzeitgen 96kHz als Studiostandard schon nicht mehr. Der DSP müsste schon bei einem TAP1024 fast 100 Mio Multiplkationen + Akkumulationen durchführen. 1024 TAPs Filterlänge reichen aber bei 96kHz nur auf 94Hz herunter. Gemäss Lambda/4 = 24 Hz könnte man argumentieren, dass es fürs Audio reicht. Realistisch sind aber eher 192kHz und eine Grenzfrequenz von 12 Hz, also eine Filterlänge von 16384. Damit landen wir schon bei 3Mia Operationen. Ich rechne bei einem 200MHz FPGA je Audiokanal 16 DSP-Kanäle, bei 7:1 Surround also 128 lanes. Wenn man mit Halbbandfilterung und einer Filterlängernverkürzung je Oktave arbeitet, braucht man die Hälfte.
Jürgen Schuhmacher schrieb: > 1024 TAPs Filterlänge reichen aber bei 96kHz nur auf 94Hz herunter. Wieso das denn? Der Frequenzgang hat mit der TAP-Zahl direkt nichts zu tun, soweit mir bekannt. Das ist nur eine Frage der Genauigkeit. Mehr TPAs = mehr Genauigkeit der Filterkurve.
Thomas Werner schrieb: > Der Frequenzgang hat mit der TAP-Zahl direkt nichts zu > tun, soweit mir bekannt. Das ist nur eine Frage der Genauigkeit. Mehr > TPAs = mehr Genauigkeit der Filterkurve. Eben und jetzt vergleiche mal die Filterfrequenzgänge in den beiden Fällen der verdoppelten Abtastfrequenz mit derselben TAP-Zahl miteinander, wenn Du einen niederfrequenten Bandpass bauen möchtest.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.