Can Kosar

Kategorie: Audiotechnik (page 1 of 6)

Software-Struktur eines Effektblocks

Bei der Audioverarbeitung hat objektorientierte Programmierung große Vorteile. Dazu zählen:

  • Mehrmalige Instanzierung der Sub-Blöcke in anderen Blöcken
  • Mehr Speicherverwaltungsmöglichkeiten
  • Übersichtlichere und verständlichere Programmstruktur

Besonders die Möglichkeit der mehrmaligen Instanzierung der Sub-Blöcke in anderen Blöcken ist ein entscheidendes Argument für die Wahl einer objektorientierten Sprache. Aus dem Grund wurde z.B. das Projekt Flex 500 mit C++ programmiert. Dabei ist jeder Effektblock als eine Klasse realisiert (,die ggf. andere Klassen instanzieren kann).

Die Grundelemente einer Klasse sehen folgendermaßen aus:

Standardinhalt einer Klasse beinhaltet folgende Methoden bzw. Attributen:

  • init() : Hier werden der Block, Subblöcke und Initialparameter initialisiert.
  • start(): Diese Methode wird ausgeführt, wenn ein Block gestartet wird.
  • stop(): Diese Methode wird ausgeführt, wenn ein Block gestoppt wird. (z.B. reset() triggern)
  • set_parameter_xyz(): Mit diesen Methoden, werden die Parameter, die vom Controller mitgeteilt werden verarbeitet und die Klassenparameter aktualisiert.
  • status: Das ist der Flag, ob der Block aktiv oder inaktiv ist.

Simulationsumgebung für DSP-FX

Die Effekte und die Algorithmen auf dem Target zu testen, ist aufwändig. Aus dem Grund ist eine Simulationsumgebung entstanden, um die Algorithmen in Windows Umgebung effizient zu testen.

Das Programm kann als ein Wrapper für die Hauptroutine vorgestellt werden. Es wird hauptsächlich eine Audio-Datei eingelesen und serialisiert. Dann wird der Inhalt der Audio-Datei serialisiert und in die DSP-Hauptroutine gespeist. Das Ergebnis wird dann wiederum deserialisiert und als eine Ergebnisdatei abgelegt.

 

Main-Routine

Der Ablauf der Main-Routine ist im oberen Diagramm gezeigt. Die Implementierung ist folgendermaßen:

Der Rest ist gleich wie im Target code.

Konfiguration / Updates

Auf dem Target werden die Benutzerinteraktionen interpretiert, um die DSP-Einstellungen zu aktualisieren. Bei der Simulation gibt es keine Echtzeit Interaktionen. Daher werden die Module mit erwünschten Einstellungen „initialisiert„. Dann laufen die Module mit diesen festen Einstellungen.

Ausnahme hierzu ist die Aktivierung der Module. Auf dem Target wird ein Wort gesendet, wo jedes Bit auf den Status eines Moduls hinweist. Hierbei muss dieser Hash aktuell manuell modifiziert werden, um die Module zu aktivieren:

Ressourcen

Der Code samt Eclipse-Projekt ist auf Github verfügbar:

Die DSP-Simulation Quellcode vom   herunterladen.

 

 

STM32 SAI Konfiguration

STM32 besitzt je nach Chipvariante eine serielle Audio-Schnittstelle SAI. Durch diese Schnittstelle kann über übliche Protokolle mit Audio-Codecs kommuniziert werden.

Audio-Clocks

Das Codec und die SAI-Schnittstelle müssen synchronisiert werden. Dabei gibt es konkrete Vorgaben bzw. Randbedingungen seitens Codecs.

  • Audio-Abtastfrequenz F_s wählen.
  • Den Multiplikator k_{MCLK} (Codecs haben oft Multiplikatortabellen z.B. 256 oder 512 bei 48kHz) wählen.
  • Daraus die erforderliche Master-Clock-Frequenz berechnen. (Oft F_{MCLK}F_s \cdot k_{MCLK})
  • Master-Clock-Quelle konfigurieren (Externer Quarz bzw. interne Clockquellen)

Übertragung

Unter dem Aspekt gibt es (wie für viele andere Hardwarekomponenten) hauptsächlich drei Möglichkeiten eine Codec-Schnittstelle zu steuern bzw. auszulesen:

  1. Normaler Modus (Blockierend)
  2. Interrupt-Modus (Nicht-blockierend)
  3. Per DMA auslesen (Nicht-blockierend)

Bei einer echtzeitkritischen Audio-DSP-Anwendung kommt nur DMA-Schnittstelle in Frage. Die Konfiguration der Software und Hardware ist hier beschrieben.

SAI und DMA Konfiguration

Beim Flex 500 ist feste 48kHz Abtastrate gewählt. Bei CS4272 kann der Multiplikator 256 oder 512 gewählt werden. Um auch zukünftig 96kHz zu unterstützen wurde hierbei 512 gewählt. Zu Stabilitätszwecken wurde für einen externen Quarz entschieden. Die Frequenz des Quarzes berechnet sich also als

(1)   \begin{equation*} F_{MCLK}=F_S \cdot k_{MCLK} = 48000 \cdot 512 = 24,576 MHz \end{equation*}

In dem Fall ist der Codec der Master und generiert den Bitclock. Der DSP ist Slave und erhält den Bitclock und dazugehörige Streams.

Die Konfiguration sieht folgendermaßen aus:

Low level Treiber: (*_hal_msp.c)

SAI Konfiguration

Starten vom Treiber

DMA Interrupts setzen die Flags. Die Software Architektur ist hier beschrieben.

Die CODEC-Treiber sind hier beschrieben:

CS4272 CODEC-Schnittstelle für Nucleo H743

WM8731 CODEC-Schnittstelle für Nucleo H743

Ressourcen

Der vollständige Code vom Communication Stack befindet sich auf den Repositories vom Controller und DSP unter den Ordnern „hw„.

DSP – Targetcode vom herunterladen

Controller- Targetcode vom   herunterladen

STM32 ADC: Expression-Pedal Steuerung

STM32 hat je nach Chipvariante einen oder mehrere Analog-Digital-Wandler (ADC).

Der ADC konvertiert die am analogen Eingang anliegende Spannung in einen binären Wert. Dafür braucht er allerdings ein Paar Zyklen- je nach Einstellung aber mindestens um die 3 Zyklen. Zudem läuft ADC mit niedrigerer Frequenz als der Cortex-Kern. Man muss also wissen, dass eine Konvertierung einige Prozessorzyklen lang dauert.

Unter dem Aspekt gibt es (wie für viele andere Hardwarekomponenten) hauptsächlich drei Möglichkeiten einen Analog-Digital-Wandler zu steuern bzw. auszulesen:

  1. Normaler Modus (Blockierend)
  2. Interrupt-Modus (Nicht-blockierend)
  3. Per DMA auslesen (Nicht-blockierend)
Normaler Modus

In diesem Modus läuft das Sampling im Hauptprogramm. Das heisst, man triggert das Sampling an, wartet(!) darauf, dass das Sampling fertig ist und macht weiter im Hauptprogramm. Das bedeutet viele verlorene Zyklen und darf nur in Ausnahmefällen bzw. in nicht leistungskritischen Applikationen eingesetzt werden.

Interrupt Modus

Im Interrupt-Modus stößt das Hauptprogramm das Sampling an und macht weiter mit seinen Aufgaben. Wenn das Sampling fertig ist, löst die ADC-Hardware einen Interrupt aus. Mit Hilfe dieses Interrupts kann dann dem Hauptprogramm mitgeteilt werden, dass nun das Register den neuen Digitalwert beinhaltet.

DMA MODUS

Im DMA-Modus schaufelt die DMA-Hardware im Hintergrund die ADC-Werte. Dabei wird die ADC-Hardware in den kontinuierlichen Modus gesetzt. Das heißt, sie fängt gleich mit dem nächsten Sampling an, wenn sie mit einem fertig ist. Das ist oft der effizienteste Modus.

 

Beim Projekt Flex 500 wird z. B. das Expression-Pedal mit einem ADC interrupt-gesteuert gelesen. Der Grund dafür ist, dass man die Frequenz mit einem Timer einstellen möchte.  Die ADC-Hardware ist folgendermaßen konfiguriert. Das

Nach jedem Lesezyklus triggert man dabei das nächste Sampling. Das Interrupt wird dabei allerdings nicht benutzt, da der Zyklus kurz ist und das Interrupt sonst das Hauptprogramm unnötig oft unterbrechen würde.

Andere Möglichkeit wäre eben per DMA, dass man dabei die Hardware nur starten und stoppen muss:

Die Konfiguration des Timers ist folgendermaßen. Bei einer CPU-Frequenz von 216MHz ergibt sich eine Timerfrequenz von:

(1)   \begin{equation*} f_{TIM3}= \frac{216\cdot 10^6}{(1600+1)*(10000+1)} \approx 13.5Hz \end{equation*}

Ressourcen

Der vollständige Code vom Communication Stack befindet sich auf den Repositories vom Controller und DSP unter den Ordnern „hw„.

DSP – Targetcode vom herunterladen

Controller- Targetcode vom   herunterladen

DSP<->Controller Kommunikation

Die Hardwarearchitektur vom Flex 500 ist hier beschrieben. Die Kommunikation zwischen DSP und Controller läuft über eine SPI-Schnittstelle. Auf der Controller-Seite werden Mitteilungen interrupt-gesteuert gesendet, da die Mitteilungen von mehreren Instanzen aus geschickt werden können und DMA zu ständigen Unterbrechungen auf der DSP Seite führen würde.

Auf der DSP-Seite wird die Mitteilung, die über SPI-Schnittstelle erhalten werden, mit DMA an den Programmspeicher kopiert. Danach wird ein Interrupt ausgelöst, wonach der DSP den Befehl verarbeiten kann.

Die Struktur der Mitteilung

Die Struktur der Mitteilung ist im folgenden dargestellt.

  • Bank Id: Die ID der Effekt-Bank.
  • Type: Der UI-Controller type, der sich geändert hat: Encoder oder Button
  • Id: Der ID des UI-Controllers (Button number oder Encoder number)
  • Data: Data in (Float, 32bit, 16bit, 8bit mit oder ohne Vorzeichen)

Die Übertragung der Mitteilung

Die Mitteilung liegt im Programm im Typ „union“, der die Typen

  • Float
  • 32bit unsigned
  • 16bit unsigned
  • 8bit unsigned

beinhaltet.

Daten dieses Typs müssen über SPI übertragen werden. Dabei wird der Vorteil genutzt, dass sowohl Sender als auch der Empfänger gleiche Endianness benutzt. (Beide Cortex-M7) Das heißt, wir können einfach den Speicherbereich, wo die Mitteilung liegt, schicken. Dann castet der Empfänger auf dieselbe Union zurück und die Daten liegen in der erwünschten Struktur beim Empfänger an.

Code vom Sender

wobei ctrl_tx des Typs „Unions“ ist.

Code vom Empfänger

Ressourcen

Der vollständige Code vom Communication Stack befindet sich auf den Repositories vom Controller und DSP unter den Ordnern „com„.

DSP – Targetcode vom herunterladen

Controller- Targetcode vom   herunterladen

Hardware Architektur – Verteiltes System

Übliche Systemarchitektur eines Audioprozessorsystems wie das vom Flex 500 ist ein verteiltes System. Die Aufgaben werden dabei auf mehrere Prozessoren verteilt. Bei einer leistungs- und echtzeitkritischen Anwendung wie ein Audio-Prozessor ist das oft unverzichtbar.

Hardware-Architektur

Die Hardware-Architektur vom Flex 500 ist im folgenden Bild gezeigt:

Audio-DSP

Spezialisierte Audio-DSP-Chips

Der Kern eines typischen Audio-Prozessors ist ein DSP-Chip. Lange Zeit wurden dafür ausschließlich dafür konzipierte Audio-DSPs, wie z.B. die von Texas Instruments und Analog devices eingesetzt. Die Audio-DSPs haben Befehlsätze, die für Audiodatenverarbeitung typisch sind und eine effiziente hardwaregestütze Verarbeitung der Daten ermöglichen. Dazu gehören viele spezialisierte SIMD-Befehle. (Single Instruction Multiple data) wie MACs (Multiplier+Accumulator). Diese ermöglichen schnelle Verarbeitung von z.B. Biquad-Filtern, ein sehr verbreitetes digitales Filter oder aber auch viele andere Algorithmen, wo sequentielle Multiplikation und Addition-Folgen größerer Daten nötig ist.

MehrZweck-Mikroprozessoren (General purpose Microprocessors)

Mittlerweile sind die Leistung und die Befehlssätze der Mikroprozessoren rasant gestiegen. Heutzutage sind viele Prozessoren mehrere Hundert Megahertz schnell getaktet und bieten u. a. DSP-Einheiten für SIMDs und Gleitkommazahl-Einheiten (FPUs). Aufgrund ihrer breiten Verfügbarkeit und vielseitiger Einsatzmöglichkeiten jenseits der Audio-Verarbeitung, sind die Mehrzweck-Mikroprozessoren zu einer echten Alternative gegenüber der herkömmlichen Audio-DSPs geworden.

Ein Spitzenreiter unter denen ist die Prozessoren auf Basis von ARM Cortex-M7. Diese Prozessoren sind bis zu 600MHz getaktet, besitzen DSP und FPU Einheiten. Ein Vergleich von Cortex-basierten Prozessoren gegenüber der herkömmlichen, verbreiteten Produkte von Texas Instruments und Analog devices ist im folgenden Artikel detailliert aufgeführt:

Choosing the best processor for your DSP application

DSP capabilities of Cortex Processors

In diesen Studien ist sichtbar, dass die High-End Spezialprozessoren für manche spezialisierte Tasks wie MAC-Leistung immer noch die Nase vorne haben. Allerdings sind die Cortex Prozessoren auch sehr leistungsfähig und können ihre Stärken bei allgemeineren Tasks spielen, wofür die Spezialprozessoren keine HW-Unterstützung anbieten.

Aus den genannten Aspekten wurde für den Flex 500 ein STM32H743 mit 400MHz Taktrate, DSP und FPU-Einheiten gewählt.

Controller-Chip

Ein Controller-Chip übernimmt oft alle sonstigen Aufgaben wie die allgemeinen Verwaltungsaufgaben, GUI-Steuerung, Anzeige etc. Die Echtzeitansprüche an den Controller-Chip ist niedrig, dafür muss er viele Tasks abarbeiten. DSP und Controller-Chips unterscheiden sich voneinander vor allem in deren Softwarearchitektur.

Der DSP-Chip muss mehrere Tasks schedulen und abarbeiten. Eine Middleware wie FreeRTOS ist dafür sehr gut geeignet, wenn die Komplexität und die Tasks steigt. Man kann auch „Bare-metal“ programmieren und eigenen Scheduler schreiben.

Je nach benötigter Leistung und Peripherien kann man einen Mikroprozessor wählen, der diese Aufgaben erledigt. Auch hierbei  ist ARM Cortex-M sehr gut geeignet und verbreitet.

Beim Flex 500 muss der Mikrocontroller

  • GUI Inputs und Outpus managen
  • Eine kleine Grafikbibliothek treiben
  • Kommunikation zum DSP aufbauen.
  • Expression-Pedal und Fußschalter treiben
  • Sonstige HW steuern (Leistungsstufe etc.)

Als Controller von Flex 500 ist der STM32F767 von ST gewählt, der mit 216MHz Taktfrequenz und zahlreiche Schnittstellen all diese Aufgaben erledigen kann. Für diesen Zweck ist vermutlich auch ein kleinerer Cortex-M4 vollständig ausreichend.

Display-Treiber

Der Controller-Chip ist von der Prozessorleistung her sehr stark und besitzt  auch ein Display-Treiber. Allerdings ist die verfügbare interne RAM mit 512 sehr knapp für Grafikanwendungen. Um die interne RAM für sonstige Aufgaben freizuhalten, ist ein externer Display-Treiber gewählt.

Die Lösung für Display hängt stark von Anforderungen an. Eine sehr gute Übersicht ist im folgenden Paper von ST verfügbar:

LCD-TFT display controller (LTDC) on STM32 MCUs

Beim Flex 500 ist ein Display mit integriertem Chip ILI9341 eingesetzt.

 

Flex 150 – Analoger Bassgitarrenverstärker

Flex 150 ist ein Experimentierprojekt für die Umsetzung eines analogen 150W-Class-AB-Bassgitarrenverstärkers.

 

Unter dem Bastelgehäuse stecken:

  • 150W-Class-AB-Verstärker
  • Kleinsignalstufe mit EQ und Compressor
  • 200W lineares Netzteil für die Leistungsstufe
  • 30W lineares Netzteil für die Kleinsignalstufe

Ressourcen

Die Design- und Simulationsressourcen von diesem Projekt können hier heruntergeladen werden:

Flex150 Leistungsverstärker LTSPice Simulationsdateien herunterladen.

Flex 150 KiCAD-Designdateien herunterladen.

150W Class-AB Verstärker-Design

Das Design eines 150W-Mono-Class-AB-Verstärkers ist im folgenden dokumentiert. Dieser Verstärker ist im Bassgitarrenverstärker-Projekt Flex 150 eingebaut.

Architektur

Open-Loop vs. Closed-Loop Architektur

Die ersten Verstärker hatten eine „open-loop“-Architektur, d.h. sie waren offene Steurung, die aus einer Spannungsverstärker- (Voltage amplifier stage) und einer Stromverstärkerstufe bestand.

Die Spannung wurde durch einfache Transistor (oder Röhren-)schaltungen verstärkt. Das allein bringt sehr bescheidene Ergebnisse. Der wirkliche Durchbruch bei Audio-Verstärkern ist durch die Einführung der „Closed-Loop“-Verstärkern erreicht. Das heißt, der ganze Verstärker war ein Regelkreis. Da die Spannungs- und Stromverstärkerstufen sehr hohe Verzerrungen aufweisen (s. Beitrag zu VAS) ist Ausgangssignal abgezweigt, skaliert und vom Eingangssignal abgezogen. Diese neue Stufe hieß Differenzverstärker und die Architektur sah folgendermaßen aus:

Das heißt, die Fehler, die durch VAS und Puffer entstehen, sind wieder in den Eingang negativ zurückgeführt, dass diese wieder ausgebügelt werden.

Komponenten

Differenzverstärkerstufe

Die Differenzverstärkerstufe ist in diesem Beitrag erklärt und die Dimensionierung berechnet.

Spannungsverstärkerstufe

Die Spannungsverstärkerstufe ist in diesem Beitrag erklärt und die Dimensionierung berechnet.

Stromverstärkerstufe und Rückkopplung

Eine sehr gute Quelle, in der das Leistungsverstärkerdesign ausführlich erklärt wird ist das praktische Standardwerk vom Bob-Cordell: Designing Audio power amplifiers.

150W Class-AB Verstärker

Für die praktische Umsetzung sind die Ressourcen eines hochwertigen 150W-Class-AB Verstärkers verfügbar, der im Projekt Flex 150 eingebaut ist.

Ressourcen

Die Leistungsstufe im Projekt Flex-150 ist ein Class-AB Verstärker entwickelt mit min. 150W Dauerlast. Spitzenlasten liegen weit höher, da das Design auf linearem Netzteil basiert. Die Design- und Simulationsressourcen von diesem Projekt können hier heruntergeladen werden:

Flex 150 Bassgitarrenverstärker

Flex 150 Leistungsverstärker LTSPice Simulationsdateien herunterladen.

Flex 150 KiCAD-Designdateien herunterladen.

Tuner: Darstellung der Noten und Abweichungen

Nachdem die Frequenz ermittelt wurde, muss nun dem Anwender dargestellt werden, welche Soll-Note erkannt wurde und wieviel die berechnete Ist-Note von der Soll-Note abweicht, damit dieser sein Instrument stimmen kann.

Abschätzung der Soll-Note

Dabei wird gesucht, welcher Notenfrequenz, die gemessene Frequenz am nächsten ist. Da die Frequenzskala logarithmisch ist, müssen die Schranken von einzelnen Noten bestimmt werden, die von der Hauptfrequenz +-50 cent entfernt sind.

Berechnung der Schranken

Die Schranken, die 50 cent von der Hauptfrequenz entfernt sind, werden zunächst einmalig berechnet. Wenn sich die Kammertonfrequenz f_{KT} (z.B. A4=440Hz) ändert, müssen die Schranken wieder berechnet werden, aber nicht in jedem Messzyklus.

Die Frequenzen der Hauptnoten berechnen sich als

(1)   \begin{equation*} \begin{aligned} f_{i,50c}&=\frac{f_{KT}}{ 2^{\frac{i}{12}}}\\ i&\in \mathbb{N} \end{aligned} \end{equation*}

Dann können wir die 50 cent verschobene Frequenzen als

(2)   \begin{equation*} \begin{aligned} f_{i,50c}&=\frac{f_{KT}}{ 2^{\frac{i-0.5}{12}}} \\ i\in \mathbb{N} \end{aligned} \end{equation*}

berechnen.

Die Implementierung kann folgendermaßen realisiert werden:

Suche nach den Schranken

Dafür eignet sich der binäre Suchalgorithmus, wenn wir keine Vorschätzung haben. Falls wir eine Vorschätzung haben (ein guter Ansatz ist die letzte gemessene Schranke zu nehmen) eignet sich auch die lineare Suche.

Im folgenden ist die Implementierung mit einem modifizierten binären Suchalgorithmus gezeigt.

Berechnung der Abweichung

Die Abweichung von der Soll-Note kann folgendermaßen berechnet werden.

Für die Zuordnung des Notenindex zur Notenbezeichnung ist ein String-Array hinterlegt.

Der gesamte Ablauf der Notenfindung sieht also folgendermaßen aus.

Ressourcen

Vollständigen Target-Code der Tuner-Anzeige vom Github herunterladen.

Eine effiziente Methode zur Frequenzerkennung

Die Frequenzerkennung (engl. Pitch detection, frequency detection) ist ein Prozess, mit dem man die dominantesten Frequenzen eines Audio-Abschnitts berechnet. Hierbei muss betont werden, dass ein Audio-Abschnitt nicht eine einzige Schwingung mit einer Frequenz besitzt. Er ist vielmehr eine Zusammensetzung von vielen Grundschwingungen, die sich zu jedem Zeitpunkt ändert. Wir nehmen z.B. die Gitarre: Wenn wir eine Saite zupfen, entstehen mehrere harmonische Grundschwingungen und ein paar nicht-harmonische Störschwingungen, die der Natur des Instruments geschuldet sind. Wir hören quasi ein „Bouqet“ aus Grundschwingungen. Wir als Menschen, nehmen deuten (zumindest oft) die dominanteste Schwingung als Grundfrequenz wahr. Die Aufgabe ist nun also diese Grundfrequenzen herauszufinden. Das ist eine sehr heikle Aufgabe, weil

  • die Amplituden der dominantesten Schwingungen sich kontinuierlich ändern
  • die dominanteste Schwingung sich im Laufe des Sample-Abschnitts ändern kann, (obwohl der ganze Sample auf eine Note deuten kann)

Die Anforderungen an einen Tuner können folgendermaßen zusammengefasst werden:

  • Aktualisierungsrate > f_s=10Hz
  • Minimale Frequenz: f_{min}=27,5Hz (A0)
  • Maximale Frequenz= f_{max}=440Hz (A4)
  • Messgenauigkeit:= \Delta_{max}=1cent
  • Effiziente Berechnung (abhängig vom eingesetzten DSP)

Mathematische Ansätze

Es gibt verschiedene mathematische Ansätze für die Umsetzung der Frequenzbestimmung:

  • Fourier-Transformation
  • Hartley-Transformation
  • Auto-Correlation

Die Fourier und Hartley-Transformationen basieren auf den Ansatz, dass man das Signal erst in Frequenzbereich transformiert und das Frequenzspektrum ermittelt. Für niedrige Frequenzen kann das eine geeignete Methode sein, um 1 Cent Genauigkeit zu erreichen. Allerdings wird die Transformation sehr langsam, wenn wir das Spektrum über mehrere 100Hz mit Hundertstel-Hertz-Genauigkeit ermitteln wollen. Denn die Genauigkeit der Fourier-Transformation müssen wir über das ganze Spektrum festlegen. Anders bei der Auto-Korrelation:

Auto Korrelation

Das Prinzip der Auto-Korrelation (Selbst-Übereinstimmung) ist relativ einfach. Wir multiplizieren unser Signal mit sich selbst mit einem zeitlichen Offset. Danach erhalten wir einen skalaren Wert. Dieser Wert gibt uns eine quantitative Aussage darüber, wie das Signal bei diesem Offset mit sich selbst übereinstimmt. Wenn wir dann die Offsets finden, bei denen die Korrelation am Höchsten ist, können wir daraus die Frequenzen ermitteln. Die Frequenz wäre dann einfach der Kehrwert vom Offset.

Der Algorithmus sieht folgendermaßen aus:

(1)   \begin{equation*} AC(\delta)=\sum_{i=1}^{n} y(i) \cdot y(i-\delta) \end{equation*}

oder wenn das Signal im Puffer vorliegt, auch vorwärts berechnend:

(2)   \begin{equation*} AC(\delta)=\sum_{i=1}^{n} y(i) \cdot y(i+\delta) \end{equation*}

Dann erhalten wir einen Auto-Korrelationswert AC für das Offset \delta. Die Anzahl der Samples n, über die wir diesen Wert berechnen muss

  • so groß wie möglich sein, um niedrige Frequenzen abbilden zu können und
  • so klein wie möglich sein, um die Anzahl der Multiplikationen zu reduzieren.

Wenn wir bei der Messung von f_{max}=440Hz eine Genauigkeit von 1 cent haben wollen, bedeutet das eine Frequenzgenauigkeit F_{\Delta}

(3)   \begin{equation*} F_{\Delta}=440 \cdot 2^{\frac{1}{1200}}-440=0.254Hz \end{equation*}

Auf der anderen Seite, wenn wir tiefe Frequenzen gut auflösen wollen, brauchen wir einen Sampleabschnitt, der ein paar volle Schwingungen beinhaltet. Bei 4 mal 20Hz Schwingungen ergibt sich eine Sample-Anzahl von

(4)   \begin{equation*} n_{27,5Hz}=48000/27,5 \cdot 4= 6981 \end{equation*}

Also wenn wir den ganzen Frequenzbereich mit 0,3Hz Genauigkeit scannen und daraus die Autokorrelation von allen Frequenzen mit 9600 Samples berechnen, beträgt der Rechenaufwand

(5)   \begin{equation*} O_{MAC}=[(440-27,5)/0.28] 6981=10284508 \end{equation*}

Multiplikation und Additionen. Das bedeutet rund 10,2Mio. Operationen pro Scan. Bei einer Aktualisierungsrate von f_S=10Hz brauchen wir 200Mio. Rechenoperationen pro Scan – nur um Autokorrelationswerte zu berechnen. Also dieser primitiver Ansatz ist nicht geeignet, um die Frequenz auf eine effiziente Weise zu berechnen.

Ein effizienter Ansatz zur Frequenzbestimmung

Wenn wir nur an ein paar dominanten Frequenzen interessiert sind, müssen wir nicht die Auto-Korrelationswerte für das ganze Spektrum mit feiner Auflösung berechnen. Daraus entstehen einige Optimierungsansätze: Man kann erst den groben Bereich der dominanten Frequenzen berechnen und dann diese in dem Bereich suchen. Dieser Ansatz ist im unteren Diagramm dargestellt.

Die einzelnen Schritte dieses Ansatzes ist im Folgenden erklärt.

Das Spektrum RASTERN

Zuerst wollen wir das Spektrum zwischen A0 und A4, also 27,5Hz und 440Hz in so wenig wie möglich Raster teilen, bei denen wir uns sicher sind, dass nicht mehrere dominante Frequenzen drin vorkommen können. Im vorliegenden Fall möchten wir die dominante Frequenz eines Musikinstruments, konkreter Gitarre und Bassgitarre ermitteln. Für den Zweck bietet es sich an, die chromatischen Notenfrequenzen als Raster zu nehmen. Unten sind die Noten von 27,5Hz bis 440 Hz dargestellt.

Notenfrequenzen

Notenfrequenzen

Das heißt, wir können das Spektrum, dass uns interessiert, erstmal in 49 Blöcke teilen. Dann berechnen wir nur den AC-Wert, der uns interessiert. Wir ermitteln hier die Information: „Um welche Note geht’s denn überhaupt?

Zudem: Die Wahl der Noten nach chromatischen Frequenzen bei 440Hz-Stimmung, ist auch eine strategische Wahl. Denn: Die gefundenen Noten aus diesem Array werden genommen, um in ihrer Nähe nach der exakten Frequenz zu suchen. Diese Noten sind auch die erste Schätzung für die Suche. Mit der Annahme, dass dieser Algorithmus als chromatischer Tuner bei einem 440Hz-gestimmten Instrument benutzt werden soll, erwarten wir oft eine Übereinstimmung in unmittelbarer Nähe.

Zunächst werden diese Frequenzen als Offsets \delta in einem Array gespeichert:

(6)   \begin{equation*} \delta(f)=f_s/f \end{equation*}

Wir denken ab nun nicht mehr in Frequenzen f sondern in Offsets \delta.

Erforderliche Sample-Anzahl n für die Raster berechnen

Wie bereits erwähnt, brauchen wir bei tieferen Frequenzen mehr Samples für die Auto-Korrelation-Berechnung als bei höheren Frequenzen. Dafür muss man sich eine Art Güte ausdenken. Wenn man sich z.B. für eine Güte von 4 vornimmt, bedeutet das, dass man 4 volle Schwingungen einer Frequenz für die Auto-Korrelationsberechnung braucht. Das ergibt

(7)   \begin{equation*} n(\delta)=[f_s/f] \psi \end{equation*}

bei der Güte \psi.

Die Implementierung würde folgendermaßen aussehen:

Auto-Korrelationswert berechnen

Die Berechnung vom Auto-Korrelationswert ist oben beschrieben. Je nach Hardwareressourcen kann dies z.B. folgendermaßen implementiert werden.

Auto-Korrelationswert normieren

Wir haben variable Anzahl an Samples für jede Frequenz, da wir erstens tiefe Frequenzen erfassen können, andererseits bei höheren Frequenzen Ressourcen sparen wollen. Daraus ergeben sich Auto-Korrelationswerte, die nicht untereinander vergleichbar sind. Wir normieren diese deshalb nach der Länge der Samples, mit denen sie berechnet wurden. Damit kann man die Amplituden einzelner Raster miteinander vergleichen.

Extrema des Spektrums (PEAKS) ermitteln

Jetzt haben wir das Spektrum, d.h. die AC-Werte für jeden Rasterpunkt, ermittelt. Wir müssen nun dort herausfiltern, welche Offsets wir brauchen. Dieser Teil ist etwas „tricky“ und beruht auf folgenden Erfahrungswerten für Gitarren und Bass-Stimmung:

  1. Bei einer Einzelsaite entstehen u. a. zwei deutlich dominante Peaks.
  2. Die Peaks sind die ersten Harmonischen voneinander (f_1/f_2=2)
  3. Die Amplituden der beiden Peaks sind sehr ähnlich und wechseln sich oft beim Ausklingen.
  4. Der tiefere Peak ist aussagekräftiger, da man dadurch die Frequenz (ohne Oversampling) präziser messen kann (n_2>n_1)

Deshalb versuchen wir im folgenden Schritt

  1. Zwei dominanteste Offsets (Peaks) aussuchen
  2. Diese sortieren

Das wird folgendermaßen implementiert.

Nach den exakten Frequenzen (Offsets) suchen

Wir haben nun zwei Frequenzen ermittelt, bei denen wir wissen, unsere gesuchte Frequenz liegt in deren unmittelbare Nähe. Man kann sich das ungefähr folgendermaßen vorstellen:

Rendered by QuickLaTeX.com

Es existieren zahlreiche Suchalgorithmen. Je nach Anwendung können diese Vor- und Nachteile haben. Eine Übersicht ist hier verfügbar. In dem Fall bieten sich hauptsächlich zwei Suchalgorithmen

Die Wahl zwischen diesen Algorithmen sind im vorliegenden Fall schwierig. Wenn die gesuchte Frequenz in der Ferne liegt, ist binäre Suche vorteilhafter. Wenn diese aber in der Nähe liegt, ist lineare Suche vorteilhafter.

Die Implementierung dieser Suche ist folgendermaßen zu realisieren:

Stochastische Abschätzung der GESUCHTEN Frequenz

Nachdem die exakten zwei Frequenzen ermittelt wurden, merkt man, dass dieser Wert in einem kleinen Intervall schwankt, was der Natur der Instrumente geschuldet ist. Nun muss

  • die Plausibilität der berechneten Frequenzen bewertet und
  • der Frequenzverlauf gemittelt werden,

damit der Benutzer eine vernünftige Frequenz- bzw. Notenanzeige hat. Dafür wird eine Toleranz \sigma eingeführt, innerhalb dessen die Frequenz schwanken darf. Wenn eine Messung diese Toleranz überschreitet, vermutet man ein Notenwechsel. Also entweder wird eine andere Saite gezupft oder so stark korrigiert, dass man diese Messung nicht mehr in die Mittelung einfließen darf. Danach wird die Mittelung zurückgesetzt und weiterhin auf eine Messungfolge gewartet, wo alle Messungswerte innerhalb der Toleranz liegen. Danach wird die Note wieder gezeigt.

Die Implementierung kann folgendermaßen aussehen:

Ressourcen

Hiermit wurde der Ablauf einer Frequenzermittlung für eine Tuner-Applikation gezeigt. Der vollständige Target-Code für DSP und der Simulationscode für Windows kann vom GitHub heruntergeladen werden.

ältestenposts

Rechte © 2024 Can Kosar

Mit Unterstützung von Wordpress, QuickLaTeX und Design von Anders NorenSeitenanfang ↑