Forum: Digitale Signalverarbeitung / DSP / Machine Learning DSP-Plattform für Audio


von Jan (Gast)


Lesenswert?

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

von mmacs (Gast)


Lesenswert?

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.

von Thomas (Gast)


Lesenswert?

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.

von Sascha (Gast)


Lesenswert?

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.

von K. (Gast)


Lesenswert?

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!

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von Helmut S. (helmuts)


Lesenswert?

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.

von Thomas (Gast)


Lesenswert?

Hört sich an, las stiege Ti aus dem Sektor aus?

von Sascha (Gast)


Lesenswert?

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.

von Sascha (Gast)


Lesenswert?

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.

von K.U. (Gast)


Lesenswert?

@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.

von Sascha (Gast)


Lesenswert?

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.

von K.U. (Gast)


Lesenswert?

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.

von Sascha (Gast)


Lesenswert?

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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von Michel (Gast)


Lesenswert?

Zwischenfrage: Wofür benötigt man die vielen Allpässe? Sind das 
Phasenschieber?

von Sascha (Gast)


Lesenswert?

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.

von Sascha (Gast)


Lesenswert?


von K.Unger (Gast)


Lesenswert?

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.

von Sascha (Gast)


Lesenswert?

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.

von Maik W. (werner01)


Lesenswert?

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

von K. (Gast)


Lesenswert?

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.

von Maik W. (werner01)


Lesenswert?

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?

von MB (Gast)


Lesenswert?

Für deine Anforderungen ist das 
http://ch.farnell.com/texas-instruments/tmdx5505ezdsp/entwicklungsbord-ezdsp-usb-stick/dp/1796123
ideal... Hab selbst eines. Gruss

von Klaus (Gast)


Lesenswert?

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,

von Maik W. (werner01)


Lesenswert?

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...?

von Klausi (Gast)


Lesenswert?

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.

von Maik W. (werner01)


Lesenswert?

Klausi ich habs begriffen.
Und danke "MB" für deinen Link. Da muß halt einfach andere Hardware her!

danke

von Jan (Gast)


Lesenswert?

@MB

Danke für den Link, dass Teil gefällt mir sehr gut. Werde es mal damit 
probieren, zumal es bezahlbar ist.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Leider rechnet dieser DSP nur mit 16 Bit, das ist für Audio etwas wenig.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Klaus (Gast)


Lesenswert?

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?

von Klausi (Gast)


Lesenswert?

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

von Maik W. (werner01)


Lesenswert?

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.

von Uwe (Gast)


Lesenswert?

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.

von Maik W. (werner01)


Lesenswert?

Ja da habsch das nicht kapiert, danke für die Info...

von Helmut S. (helmuts)


Lesenswert?

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.

von Strubi (Gast)


Lesenswert?

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

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Klausi (Gast)


Lesenswert?

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

von Peter (Gast)


Lesenswert?

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

von Fredi (Gast)


Lesenswert?

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.

von Tom W. (Gast)


Lesenswert?

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?

von Audiorüpel (Gast)


Lesenswert?

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.

von Tom W. (Gast)


Lesenswert?

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?

von Strubi (Gast)


Lesenswert?

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

von Tom W. (Gast)


Lesenswert?

Die Simulationsfähigkeit und Flexibilität würde ich bei DSPs aber höher 
einstufen, oder?

von Strubi (Gast)


Lesenswert?

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?

von J. S. (engineer) Benutzerseite


Lesenswert?

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?

von Strubi (Gast)


Lesenswert?

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...

von high tec ingenieur (Gast)


Lesenswert?

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.

von Tom W. (Gast)


Lesenswert?

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 ?

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Tom W. (Gast)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Tom W. (Gast)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.