Lade Inhalt...

Entwicklung eines nativen Programms unter Unix zur synchronen Visualisierung von Audiosignalen im Spektralbereich

Magisterarbeit 2003 139 Seiten

Tontechnik

Leseprobe

Inhaltsverzeichnis

1 Einleitung
1.1 Einordnung der Arbeit
1.2 Aufgabenstellung

2 Grundlagen
2.1 Digitale Signalverarbeitung
2.1.1 Digitale Audiosignale
2.1.2 Visualisierung
2.2 Fast Fourier Transformation (FFT)
2.2.1 Frequenzauflösung
2.2.2 Leckeffekt
2.3 Linear Predictive Coding (LPC)
2.3.1 Klassifizierung der LPC
2.3.2 Prinzip der LPC
2.3.3 Autokorrelationsmethode
2.3.4 ÜbertragungsfunktiondesFilters
2.4 Fensterung
2.4.1 Zeit- und Frequenzauflösung
2.4.2 ÜberlappungvonFenstern
2.5 Eigenschaften von LPC und FFT im Vergleich
2.6 Sonagramm

3 Beschreibung der Software
3.1 Voraussetzungen
3.1.1 Hardwarevoraussetzungen
3.1.2 Konfiguration der Testsysteme
3.1.3 Verwendete Software und Bibliotheken
3.1.4 Verwendete Werkzeuge
3.1.5 Kompilation des Programms
3.2 Funktionsumfang
3.2.1 Benutzerschnittstelle
3.2.1.1 Parameter
3.2.1.2 Funktion der Buttons
3.2.1.3 Menüeinträge
3.2.1.4 Internationalisierung
3.2.2 Automatisch ablaufende Prozesse
3.2.3 Presets
3.3 Signalfluss im Programm
3.3.1 Audiosignalfluss
3.3.2 Grafikausgabe
3.4 Spezifikation der Farbpalette
3.5 Implementierte Algorithmen
3.5.1 Funktionen der Signalanalyse
3.5.1.1 Audioeingabe
3.5.1.2 Fensterung der Daten
3.5.1.3 Berechnung der FFT
3.5.1.4 Berechnung der LPC
3.5.1.5 Berechnung des Frequenzgangs
3.5.1.6 Hochpassfilterung
3.5.2 Visualisierungsfunktionen
3.5.2.1 Wellenformanzeige
3.5.2.2 Spektraldarstellung
3.5.2.3 Sonagrammanzeige
3.5.2.4 Farbpalettenansicht
3.5.2.5 Notensystem
3.5.3 Mausfunktionen
3.6 Programmablauf

4 Evaluation
4.1 Auswertung der Algorithmen
4.1.1 Berechnung der LPC
4.1.1.1 Anzahl der LPC-Koeffizienten
4.1.1.2 Berechnung des Hochpassfilters
4.1.1.3 ÜberlappungderFenster
4.1.2 Berechnung der FFT
4.1.3 Speicherverwaltung
4.1.4 Grafikausgabe
4.1.5 Synchronisation von Audio und Grafik
4.2 Oberfläche
4.3 Geschwindigkeit
4.4 Plattformunabhängigkeit
4.5 Aufgetretene Probleme und deren Lösungen .
4.6 Ungelöste Probleme und deren Ursachen

5 Fazit

6 Ausblick

Literaturverzeichnis
A Quellcode
B Beispielsonagramme

Index

Abbildungsverzeichnis

3.1 Screenshot von SonaSound
3.2 Signalfluss
3.3 Originale Farbpalette
3.4 Interpolierte Farbpalette
3.5 Farbpalette
3.6 Frequenzgang des Hochpassfilters mit verschiedenen Koeffizienten

B.1 Sonagramm Chormusik: J. S. Bach:
B.2 ”AgnusDei“ausderH-Moll-Messe Sonagramm Geräusche: Gerard Grisey:
B.3 Sonagramm Sprache: ”Jourcontrejour“ ”Soundcheckisthedefinitiveaudiotest-disk“
B.4 Sonagramm Orchestermusik: ”DasgroßeTorvonKiew“
B.5 Sonagramm Rock-/Popmusik: Silje Nergaard:

Tabellenverzeichnis

”There’sTroubleBrewing“

2.1 Tiefste darstellbare Frequenzen in Abhängigkeit von der Puffergröße
2.2 Eigenschaften von FFT und LPC im Vergleich

3.1 Testsysteme
3.2 Parameter der Presets

1 Globale Header-Datei: sonasound.h

2 Audio-Initialisierung: audioInit.c

3 Audio-Engine: audioIo.c

4 GUI-Callback-Funktionen: callbacks.c

5 Kurzzeitspektrum-Anzeige: fft.c

6 OpenGL-Funktionen: glDraw.c

7 Initialisierung: globalsInit.c

8 Hilfsfunktionen: helpers.c

9 GUI: interface.c

10 LPC: lpc.c

11 Farbpalette: palette.h

12 Hauptprogramm: main.c

13 Sonagramm-Anzeige: sonogram.c

14 Unterstützende Funktionen für das GUI: support.c

15 Wellenform-Anzeige: waveForm.c

1 Einleitung

Die zur Anwendung kommenden Grundlagen der digitalen Signalverarbeitung werden in Ab- schnitt 2 auf Seite 4 dargestellt. Insbesondere wird die Berechnung des Spektrums eines Signals mit verschiedenen Algorithmen erläutert. Die schließlich implementierte Form der Algorithmen wird zusammen mit der Struktur des Programms ab Abschnitt 3.1 auf Seite 16 beschrieben.

Nach einer Evaluation der angewendeten Algorithmen im Hinblick auf Genauigkeit und Geschwindigkeit in Abschnitt 4 auf Seite 49 werden dort ebenso die Oberfläche des Programms und die Realisierung der weiteren in der Aufgabenstellung (s. Abschnitt 1.2) gegebenen Gesichtspunkte erläutert.

Ein Ausblick auf Erweiterungen und Möglichkeiten des Programms wird in Abschnitt 6 auf Seite 60 gegeben.

1.1 Einordnung der Arbeit

Audio-Visualisierungsprogramme werden in vielen Anwendungsgebieten benötigt. Seien es pho- netische Fragestellungen, musikpädagogische Ansätze oder die musikwissenschaftliche Analyse. Die Möglichkeit, die jeweilige Aufgabe auf einem Rechner erledigen zu können, der bereits vor- handen ist und nicht mit speziellen Komponenten erweitert werden muss, erleichtert die Arbeit für den Anwender.

Moderne Standardrechner können aufgrund ihrer Leistungsfähigkeit die Aufgaben von DSPs[1] übernehmen. Prozessoren wie der Athlon-XP von AMD, der Pentium IV von Intel und der G4 von Motorola besitzen bereits SIMD[2]-Erweiterungen, die die Nachteile eines Universalprozes- sors gegenüber DSPs ausgleichen können. Insbesondere die Geschwindigkeit der Verarbeitung von Fließkommazahlen wird durch diese Erweiterungen erhöht[3]. Des Weiteren haben Standard- grafikkartenprozessoren eine Geschwindigkeit erreicht, die in manchen Fällen der des Hauptpro- zessors in nichts nachsteht.

Verwendet man diese leistungsfähige Hardware mit einem leistungsfähigen Betriebssystem, können viele bisher den DSPs vorbehaltene Aufgaben von einem Standardrechner übernommen werden, ohne dass dessen Leistungsgrenze erreicht wird.

Insbesondere im Bereich der Unterhaltung ist eine hohe Optimierung der Software festzu- stellen. So nimmt ein Abspielprogramm für mp3-Dateien[4] auf einem modernen Rechner keine wahrnehmbare Rechenzeit mehr in Anspruch, während dessen Benutzung noch vor einigen Jah- ren eine deutliche Einschränkung der nutzbaren Prozessorleistung bedeutet hat. Im Lieferumfang dieser Programme ist immer eine Form der Audio-Visualisierung enthalten, die ebenfalls nur sehr wenig Rechenleistung in Anspruch nimmt. Somit reicht die Rechenleistung im Regelfall auch f ür ein komplexes Visualisierungsprogramm aus.

Mit der weiten Verbreitung von Linux und der Einführung des Unix-basierten Mac OS X ist die Implementation des Programms auf Unix-Basis ein sinnvoller Ansatz, um eine maximale Portabilität zu erreichen. Sowohl Macintosh-Rechner als auch intelkompatible PCs können komfortabel mit einem Unix-Derivat[5] betrieben werden. Darüberhinaus sind in vielen Rechenzentren Unixrechner wie SUN- oder SGI-Systeme weit verbreitet.

In Verbindung mit kostengünstiger PC-Hardware stellt Linux die optimale Plattform für hoch- wertige Software dar. Da dieses Betriebssystem weiterhin auf vielen verschiedenen Rechnerarchi- tekturen lauffähig ist und oft alte Hardware in adäquate Arbeitsplatzrechner verwandeln kann, ist es eine wesentliche Eigenschaft des Programms, unabhängig von spezieller Hardware zu sein.

Die Lizensierung des Programms unter der GPL[6] erfordert die Nutzung frei verwendbarer Bibliotheken, was angesichts der hohen Qualität von quelloffener Software keinerlei Einschränkung, sondern einen Gewinn bedeutet.

Es wird in dieser Arbeit beschrieben, wie ein komplexes Audio-Visualisierungsprogramm so implementiert wurde, dass Geschwindigkeit und Art der Ausgabe einen Betrieb parallel zu anderen Anwendungen erlauben, ohne deren Betrieb stark zu beeinträchtigen[7].

Die Entwicklung von Signal-Visualisierungssystemen findet am Institut für Kommunikati- onswissenschaften der Technischen Universität Berlin seit 1978 [Bec78] statt. Im Rahmen des Projekts Gehörlosenhilfe des BMFT[8] wurden einige weitere Systeme ([Hob93, Kle94, Vei99]) ent- wickelt, deren Fähigkeiten mit der rapiden Entwicklung der Computer zunahmen (nach [HK99]). Diese Arbeit ist nicht mehr in dieses Projekt eingebunden, nutzt aber die Erkenntnisse der vor- angegangenen Arbeiten.

1.2 Aufgabenstellung

In dieser Arbeit wurde ein Echtzeit[9]-Audio-Visualisierungssystem entwickelt, das ähnlich den Systemen [Kle94] und [Vei99] arbeitet, ohne wie diese auf spezielle Hardware (DSP-Karten oder bestimmte Grafikkartenmodelle) angewiesen zu sein. Die native[10] Implementierung der Signalverarbeitung und die Plattformunabhängigkeit standen im Vordergrund:

- Wie im System [Vei99] wird eine hardwareunabhängige Schnittstelle zur Grafikausgabe verwendet.
- Das Programm ist nicht auf ein Betriebssystem eingeschränkt, sondern ISO C99-konform geschrieben und modular aufgeb]aut, um den Austausch des GUI[11] zu ermöglichen bzw. einzelne Module als Bibliotheken verwendbar zu machen.

- Die Signalverarbeitung findet vollständig auf der CPU[12] des jeweiligen Rechners statt, da die momentane Rechenleistung mittlerer Systeme bei weitem ausreichend ist, diese Aufgaben zu übernehmen.
- Das Programm ist nicht auf Sprachsignalverarbeitung spezialisiert, sondern ermöglicht ebenso die Analyse von komplexen Musiksignalen.
- Es werden keine proprietären Standards oder Bibliotheken verwendet. Das Programm ist im Quellcode frei unter der GPL erhältlich.
- Das Programm ist in großem Maße vom Nutzer parametrisierbar.
Aus den oben genannten Gesichtspunkten ergeben sich folgende Arbeitsschwerpunkte:
- Reimplementierung der grafischen Benutzeroberfläche unter Verwendung von OpenGL und dem X-Window-System (X11).
- Implementierung aller Signal-Verarbeitungsroutinen in ISO C99 zur Verwendung auf beliebigen Prozessoren bzw. Auswahl und Verwendung geeigneter Bibliotheken für die Signalverarbeitung.
- Erstellung geeigneter Presets zur Voreinstellung sämtlicher Parameter in Abhängigkeit der zu analysierenden Signale, vor allem in Hinblick auf Musik.
- Implementierung von musikspezifischen Skalierungen der Ausgabe.

Aufgrund der erheblichen Unterschiede zwischen der alten Codebasis[13] aus und den oben ge- nannten Zielen, musste das gesamte Programm fast vollständig neu implementiert werden.

2 Grundlagen

Die rechnergestützte Visualisierung von Audiosignalen erfordert digitalisierte Signale, die entweder direkt von der Soundkarte oder aus Dateien in das Visualisierungsprogramm gelangen. Die Weiterverarbeitung bedeutet meist eine Zusammenfassung der Daten oder eine Interpolation fehlender Daten, um sie auf dem begrenzten Raum des Monitors darstellen zu können. Die Durchführung der Visualisierung in Echtzeit benötigt eine gewisse Anzahl an Datenpuffern, die zur Geschwindigkeitsoptimierung als Ringpuffer[1] ausgelegt werden.

Die folgenden Abschnitte beschreiben die theoretischen Grundlagen digitaler Signalverarbeitung in Bezug auf die Visualisierung von Audiodaten.

2.1 Digitale Signalverarbeitung

Die Verarbeitung aus analogen Signalen gewonnener digitaler Daten bedeutet immer ein Herun- tersetzen der Genauigkeit und ein Einbringen von Quantisierungsfehlern[2] durch die Begrenztheit aller Datentypen[3]. Die geeignete Wahl von Datentypen ist hauptsächlich von einem Kompro- miss zwischen Geschwindigkeit und Genauigkeit beeinflusst. Allerdings sind bei Verwendung geeigneter Datentypen die eingebrachten Fehler oft im nichtwahrnehmbaren Bereich.

2.1.1 Digitale Audiosignale

Digitale Audiodaten werden über ihre Wortbreite[4] und ihre Abtastrate[5] (FS ) beschrieben. Daraus lassen sich die Begriffe Dynamikumfang[6] und Bandbreite[7] ableiten. Die Qualität der Analog-Digitalwandlung von Audiosignalen ist bei heutigen Soundkarten meist im Bereich der CD-Qualität, wenn auch die störenden Einflüsse der anderen, hochfrequent arbeitenden Bauteile eines Rechners nicht zu vernachlässigen sind. Aus diesem Grund ist insbesondere bei hohen Anforderungen an die Qualität der Analyse eines Signals die Verwendung von Dateien[8] der direkten Aufnahme vorzuziehen, soweit dies möglich ist.

2.1.2 Visualisierung

Bei der Anzeige von Audiodaten auf einem Bildschirm stellt die im Verhältnis zur Datenmenge geringe Auflösung der Monitore immer ein grundlegendes Problem dar. In den seltensten Fällen wird die Anzahl der darzustellenden Daten der Anzahl der verfügbaren Pixel entsprechen. Somit ist ein großes Augenmerk auf die sinnvolle Zusammenfassung der Daten zu lenken.

Ein portables Programm zur Visualisierung muss die Unzulänglichkeiten in der Genauigkeit der Darstellung durch die einzelnen Systeme berücksichtigen. Farben werden von der Einstellung des jeweiligen Monitors, den Eigenschaften der verwendeten Grafikkarte und des Betriebssystems beeinflusst. Der verfügbare Raum zur Darstellung der Daten kann nicht vorbestimmt werden, weil jeder Nutzer eigene Einstellungen der Auflösung und eine eigene Fensterplatzierung vor- nimmt. Eine verlässliche Darstellung kann nur unter Inkaufnahme einer gewissen Ungenauigkeit erreicht werden.

Bei der Echtzeit-Visualisierung wird die Problematik durch die Begrenzung der höchsten Wie- derholfrequenz eines Bildes verschärft. Somit ist oft nicht die gewünschte Bildwiederholfrequenz erreichbar, die entweder zu einer flimmerfreien[9] Darstellung nötig wäre oder von der Frequenz der neu eintreffenden Daten[10] gefordert wird. Des Weiteren hängt die maximale Frequenz der möglichen Bildwiederholungen von der Wiederholfrequenz des Monitors ab, da die Aktualisie- rung der Bilddaten in Zusammenhang mit der Zeilenfrequenz des Monitors zu setzen ist.

Die Visualisierung von Audiosignalen kann in zwei Bereichen erfolgen: Zum einen wird im Zeitbereich der Schwingungsverlauf des Signals dargestellt. Diese Darstellung entspricht in etwa der Anzeige eines Oszilloskops. Zum anderen wird im Frequenzbereich die spektrale Zusam- mensetzung des Signals dargestellt. Hierfür wird eine gewisse Anzahl Daten analysiert und die Frequenzanteile innerhalb dieses Zeitabschnitts werden dargestellt. Die spektrale Analyse kann über verschiedene Algorithmen erfolgen, von denen zwei in den folgenden Abschnitten erläutert werden.

2.2 Fast Fourier Transformation (FFT)

Die Fourier-Transformation stellt eine der ältesten Methoden[11] der spektralen Darstellung dar. Prinzipiell wird hierbei das Originalsignal durch eine Kombination verschiedener Sinus- und Kosinusschwingungen mit verschiedenen Amplituden und Frequenzen dargestellt. Die Koeffizi- enten der einzelnen Schwingungen werden als Fourierkoeffizienten bezeichnet, die Synthese des Signals aus den einzelnen Sinusschwingungen wird als Fourierreihe bezeichnet. Berechnet wer- den kann die Fourier-Transformation sowohl kontinuierlich als auch diskret. In dieser Arbeit ist lediglich die diskrete Transformation von Interesse, da alle Berechnungen mit digitalen Signalen durchgeführt werden.

Die FFT stellt eine spezielle Ausprägung der Diskreten Fourier Transformation (DFT) dar, die im benötigten Rechenaufwand erheblich reduziert ist, indem Symmetrien ausgenutzt wer- den und redundante Bestandteile nicht berechnet werden. So beträgt nach [OS99, S. 635-640] der Aufwand der Berechnung einer DFT in Abhängigkeit der Anzahl der Frequenzstützstellen

(N ) N[2] komplexe Multiplikationen und Additionen, während eine FFT mit N · log2 (N ) Re- chenschritten auskommt. Das grundlegende Prinzip dieser Vereinfachung liegt in der rekursiven

Ersetzung einer DFT durch zwei DFTs mit der halben Punkteanzahl bis nur noch mehrere tri- vial zu berechnende Zweipunkt-DFTs übrig bleiben, deren Ergebnisse wieder zusammengefasst werden müssen.

Die Darstellung des Spektrums erfolgt mit Hilfe der zeitdiskreten Fourier-Transformierten in Formel 2.1.

Abbildung in dieser Leseprobe nicht enthalten

Die Anwendung der FFT auf einen nichtperiodischen Signalabschnitt, wie es bei Musik meist der Fall ist, resultiert in der periodischen Fortführung des Signalabschnitts durch die FFT. Da Rechen- und Speicherkapazität begrenzt sind, muss die in Formel 2.1 unendliche Reihe auf eine begrenzte Anzahl von Samples angewandt werden. Der theoretisch unendliche Datenstrom des zu analysierenden Signals wird in einzelne zeitlich begrenzte Stücke zerlegt, indem das Signal mit einer Fensterfunktion multipliziert wird.

Das Fenster wird im Spektralbereich mit dem Signal gefaltet[12] und verfälscht das Spektrum, weswegen die Auswahl eines geeigneten Fensters für das Analyseergebnis eine große Rolle spielt (s. Abschnitt 3.5.1.2 auf Seite 34).

2.2.1 Frequenzauflösung

Die Frequenzauflösung (Δf ) der FFT hängt von der Abtastrate und der Anzahl der FFT-Punkte ab:

Abbildung in dieser Leseprobe nicht enthalten

So beträgt bei einer Abtastrate von 44,1kHz und einer FFT-Punkteanzahl von 4096 die geringste darstellbare Frequenz ebenso wie die geringste darstellbare Differenz zwischen zwei Frequenzen 10,767Hz.

Der Zeitraum, der durch eine FFT-Analyse repräsentiert wird, entspricht der Größe des Zeitsignal-Puffers oder der Anzahl der FFT-Punkte. Ist die Länge des Puffers geringer als die Anzahl der FFT-Punkte, wird Zeropadding[13] eingesetzt (genaue Erläuterung siehe Abschnitte 2.4 auf Seite 11 und 3.5.1.3 auf Seite 37).

2.2.2 Leckeffekt

Die Berechnung der diskreten Fourier-Transformation von einer begrenzten Menge an Samples stellt eine Filterung des Signals mit der sinc-Funktion (sin(x)/x) dar. Das durch die FourierTransformation erzeugte periodische Spektrum muss zur weiteren Verwendung diskretisiert werden. Durch die Abtastung des Spektrums streuen die Energieanteile aus den Nebenkeulen des Filters Artefakte in das FFT-Ergebnis ein, die nicht im Original enthalten sind.

Von diesem Fall ist immer auszugehen, wenn es sich nicht um die Analyse eines synthetischen Signals aus einer Kombination von Sinusschwingungen der Frequenz FS/N handelt[14]. Somit werden Frequenzanteile des Signals, die nicht genau auf einer Mittenfrequenz eines Frequenzbandes liegen von mehreren angrenzenden Bändern dargestellt bzw. in einem Band werden zusätzlich die Artefakte der Nachbarbänder dargestellt.

2.3 Linear Predictive Coding (LPC)

Linear Predictive Coding stellt eine Methode dar, ein Signal mittels eines Quelle-Filtermodells zu beschreiben. Das Verfahren entstand zur effizienten Sprachkodierung. Es wird ein Modell der Spracherzeugung beim Menschen zugrunde gelegt, das als Quellsignal eine Impulsfolge annimmt, die dem Signal der Glottis[15] ansatzweise entspricht, und ein Filter erstellt, das der Filterung durch Rachen-, Mund und Nasenraum entspricht. Durch eine dynamische Änderung des Filters und der Grundfrequenz der Impulsfolge kann so mit geringer ÜbertragungsrateSprache übertragen werden, da lediglich die Filterkoeffizienten und die Grundfrequenz übertragen werden müssen.

Dasselbe Modell lässt sich nicht nur auf Sprache anwenden, sondern erzeugt auch bei Anwendung auf Musik ein Filter, das die wesentlichen Informationen des Signals wiedergibt. Allerdings ist der Aufwand zur Berechnung des Filters bei komplexen Signalen wesentlich höher als bei Sprache. Ein erheblicher Vorteil der Spektraldarstellung durch die LPC liegt in dem Fehlen der unter 2.2.2 auf der vorherigen Seite dargestellten Frequenzartefakte, weil ein kontinuierliches Filter entsteht, das dann mit beliebiger Genauigkeit abgetastet werden kann.

2.3.1 Klassifizierung der LPC

Das Verfahren der LPC gehört zur Klasse der ARMA[16]-Verfahren, d.h. die Berechnung eines Pol-/Nullstellenfilters mit der Übertragungsfunktion nach Formel 2.4 erfolgt auf der Basis des Zeitsignals, aus dem durch Autokorrelation und/oder Mittelwertbildung ein Filter zur Darstellung des Signals errechnet wird.

Abbildung in dieser Leseprobe nicht enthalten

Hierbei stellen die Nullstellen des Zählerpolynoms die Nullstellen des Filters und die Nullstel- len des Nennerpolynoms die Polstellen des Filters dar. Ein autoregressives Filtermodell w ürde bei bl = 0 erzeugt, sind alle ak = 0 erhält man ein Moving-Average-Modell. Sind Nenner- und Zählerkoeffizienten ungleich Null, resultiert ein ARMA-Modell, also eine Kombination der beiden.

Beide Modelle stammen aus der Statistik und haben die folgenden Eigenschaften:

Das AR-Modell stellt einen Wert durch die Linearkombination der vorangegangen Werte des Ausgangssignals zuzüglich des Vorhersagefehlers dar. Das MA-Modell stellt einen Wert durch die Kombination der vergangenen gleitenden Mittelwerte des Eingangssignals dar. Der Rechenaufwand für ein MA-Modell ist erheblich höher.

Im hier verwendeten Fall werden die Filterkoeffizienten autoregressiv aus den vergangenen Samples berechnet und der Zähler fest mit dem Verstärkungsfaktor G belegt, sodass der ver- wendete Algorithmus ein reines Polstellenmodell des Signals darstellt. Somit handelt es sich um ein AR-Modell.

2.3.2 Prinzip der LPC

Aus dem vorhandenen Signal wird entweder durch Autokorrelation oder Kovarianz und eine anschließende Lösung eines Differentialgleichungssystems eine Filterstruktur berechnet, deren Anwendung auf eine Impulsfolge ein Signal ergibt, das schließlich zur Berechnung des Vorhersagefehlers verwendet wird.

Die Anwendung des Filters auf das Originalsignal erzeugt das so genannte Fehlersignal. Es stellt die Differenz zwischen dem ursprünglichen und resynthetisiertem Signal dar. Dieses Fehlersignal muss eine möglichst geringe Energie enthalten, um von einer richtigen Prognose des ursprünglichen Signals durch das Filter ausgehen zu können. Die Minimierung dieses Fehlers erfolgt über die Minimierung der Summe der quadrierten Fehler.

In dieser Arbeit ist die Seite der Resynthese des Signals allerdings nicht von Interesse, sondern die Bearbeitung des Signals schließt mit der Erstellung der Übertragungsfunktion des Prädikti- onsfilters ab.

Die Analyseformel für die LPC lautet:

Abbildung in dieser Leseprobe nicht enthalten

mit den Z-Transformierten des Fehlersignals E(z), des Ursprungssignals S(z) und des inversen Filters A(z) aus den LPC-Koeffizienten.

Im Zeitbereich kann Formel 2.5 wie folgt dargestellt werden:

Abbildung in dieser Leseprobe nicht enthalten

Mit dem Fehlersignal e[n], den LPC-Filterkoeffizienten ai, der Anzahl der Koeffizienten M und dem Ursprungssignal s[n].

Die Filterkoeffizienten können auf verschiedene Weise[17] berechnet werden, von denen hier nur die im Programm verwendete vorgestellt wird. Sie hängt lediglich vom Ursprungssignal ab.

2.3.3 Autokorrelationsmethode

Die Berechnung der einzelnen Autokorrelationskoeffizienten aus dem Zeitsignal erfolgt nach Formel 2.7. Sie dient der Berechnung der Filterkoeffizienten ai über eine Rekursionsmatrix.

Abbildung in dieser Leseprobe nicht enthalten

Mit n0 und n1als Indizes der Grenzen des Bereichs, über den der Fehler minimiert werden soll. i und k stellen die Indizes der Rekursionsmatrix dar und liegen jeweils zwischen 0 und M .

2.3 Linear Predictive Coding (LPC) 2 Grundlagen

Nach [GM75] kann die quadrierte Fehlersumme über Formel ?? auf Seite ?? berechnet werden. Die Minimierung dieser Summe erfolgt über das Verfahren der kleinsten Fehlerquadrate. Aus 2.6 auf der vorherigen Seite und

Abbildung in dieser Leseprobe nicht enthalten

mit ai den einzelnen LPC-Koeffizienten, M der Anzahl der LPC-Koeffizienten.

Unter Verwendung von Formel 2.7 auf der vorherigen Seite in Formel 2.10 folgt für die Fehlersumme α folgende Berechnung:

Abbildung in dieser Leseprobe nicht enthalten

Die Minimierung von α erfolgt über die Gleichsetzung der partiellen Ableitung von Formel 2.11 mit 0:

Abbildung in dieser Leseprobe nicht enthalten

Da a0 = 1 als Initialisierungswert verwendet wird, folgt das Gleichungssystem:

Abbildung in dieser Leseprobe nicht enthalten

Das Gleichungssystem in Formel 2.13 ergibt eine Toeplitzmatrix[18] , die sich zum Beispiel mittels der Levinson-Rekursion (s. Abschnitt 3.5.1.4 auf Seite 38) lösen lässt. Zur einfacheren Darstellung werden 2.11 und 2.13 oft auch in Matrixform notiert:

Abbildung in dieser Leseprobe nicht enthalten

Wobei aT die Transponierte von a bezeichnet und C die M × M Matrix wie in Formel 3.9 auf Seite 38 bezeichnet. a und c sind Spaltenvektoren mit M Elementen.

Um eine Spitze im Spektrum durch das Filter zu beschreiben, ist ein konjugiert komplexes Polstellenpaar des Filters erforderlich.

2.3.4 Übertragungsfunktion des Filters

Das aus Formel 2.7 und 2.13 auf der vorherigen Seite berechnete Filter muss zur Darstellung in den Frequenzbereich transformiert werden. Die Übertragungsfunktion ist definiert als:

Abbildung in dieser Leseprobe nicht enthalten

Mit dem in 2.17 definierten Verstärkungsfaktor G, wobei G[2] der Energie des Fehlersignals entspricht.

Abbildung in dieser Leseprobe nicht enthalten

Das inverse Filter A(z) ist als folgendes Polynom darstellbar:

Abbildung in dieser Leseprobe nicht enthalten

Somit ergibt die Formel 2.16 mit Formel 2.17 und 2.18 die folgende Übertragungsfunktion: √

Abbildung in dieser Leseprobe nicht enthalten

Für die spektrale Auswertung des LPC-Filters muss der Wert Zählers in Formel 2.19 nach [MG76, S. 130-131] nicht neu berechnet werden, da er dem Wert α entspricht. In [Mak75a, S. 565] wird die Übertragungsfunktion in Formel 2.19 inkorrekt mit quadriertem Zählerpolynom angegeben. Dies wurde hier und in der Implementation korrigiert.

Der komplexe Frequenzgang eines Filters mit bekannter Impulsantwort[19] h[n] kann allgemein nach Formel 2.20 berechnet werden.

Abbildung in dieser Leseprobe nicht enthalten

Setzt man z = ejω und die Eulersche Identität[20] in Formel 2.20 ein, erhält man folgende in einem Programm implementierbare Formel zur Berechnung des Frequenzgangs:

Abbildung in dieser Leseprobe nicht enthalten

Hier kann die Bearbeitung abgeschlossen werden, da nun Real- und Imaginärteil des LPCFilters bekannt sind und als Spektrum dargestellt werden können.

2.4 Fensterung

Um das Ausschneiden einzelner Bereiche aus dem Zeitsignal mit möglichst geringen Artefakten im Frequenzbereich zu ermöglichen, werden die Samples mit bestimmten meist auf dem positiven Wertebereich der cos-Funktion beruhenden Faktoren multipliziert. Dieses Vorgehen stellt sicher, dass an den Rändern der Puffer keine Sprünge auftreten.

Eine geeignete Fensterung des Signals kann den Leckeffekt durch die FFT erheblich eindämmen, weil die Übertragungsfunktionen der Fenster darauf optimiert sind, die Nebenkeulen der sinc-Funktion möglichst klein zu halten. EineÜbersicht über die verschiedenen Fensterarten ist in 3.5.1.2 auf Seite 34 dargestellt.

2.4.1 Zeit- und Frequenzauflösung

Die Wahl einer geeigneten Fenstergröße hängt von den darzustellenden Frequenzen und der be- absichtigten Zeitauflösung ab. Lange Fenster resultieren in einer geringen Zeitauflösung mit einer hohen Frequenzauflösung, da die Analyse jeweils über den gesamten Fensterbereich ausgeführt wird.

Abbildung in dieser Leseprobe nicht enthalten

Formel 2.22 ergibt für FS = 48000 und p = 4096 eine Zeitauflösung von 85,333ms. Alle ÄnderungenimSignal,dieinnerhalbdieserPeriodestattfinden,werdenvonderAnalysenicht als solche dargestellt, sondern erscheinen als hohe Frequenzanteile des Signals.

Darstellung tiefer Frequenzen

Um eine komplette Periode einer Schwingung digital darzustellen, muss die Größe des Analysepuffers in Sekunden mindestens der Schwingungsdauer dieser Schwingung entsprechen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Tiefste darstellbare Frequenzen in Abhängigkeit von der Puffergröße

In Formel 2.23 und Tabelle 2.1 sind exemplarisch einige Frequenzen bei geläufigen Puffergrößen und Abtastraten dargestellt. Es sei darauf hingewiesen, dass eine Unterschreitung der theoretisch erforderlichen Puffergröße nicht automatisch bedeutet, dass die Frequenz nicht von der FFT oder LPC erfasst werden kann. Vor allem bei Verwendung der FFT wird durch den Leckeffekt immer ein Teil der Energie in die angrenzenden Bänder überstrahlen. Ebenso ist oft eine halbe Periode des Signals ausreichend, um die Frequenz zu bestimmen.

Darstellung von Frequenzdifferenzen

Etwas komplizierter wird die Wahl der geeigneten Fenstergröße bei der Bestimmung der geringsten Differenz zwischen zwei Frequenzen, die dargestellt werden soll.

Zur Detektion zweier Sinusschwingungen muss jede davon in einer getrennten Hauptkeule des Fensters auftreten. Also muss die Bandbreite der Hauptkeule des Fensters größer als die Periodendauer der Differenzfrequenz Δf = f2 − f1 der beiden Schwingungen sein.

Nach [SS02] ist:

Abbildung in dieser Leseprobe nicht enthalten

Mit der Dimension des Fensters M , der Größe der Hauptkeule als Anzahl der Frequenzbänder[21] K, der Periode P [Samples], der Frequenzdifferenz Δf [Hz] und der Periodendauer TFS [s] der Abtastfrequenz.

Aus 2.24 ergibt sich, dass die Fensterlänge zur Auflösung einer willkürlichen Differenzfrequenz Δf mindestens K mal der Periodendauer von Δf entsprechen muss. Beträgt beispielsweise die Breite der Hauptkeule des Fensters 4 Bänder der entsprechenden Frequenz, ergäbe sich in Ergänzung zu Tabelle 2.1 auf der vorherigen Seite zur exakten Auflösung eines Δf von 10Hz durch die FFT bei einer Abtastrate von 48kHz eine Fensterlänge von 19.200 Samples.

Darstellung hoher Frequenzen

Die Darstellung hoher Frequenzen stellt in der Regel kein Problem dar, da mehrere Perioden der entsprechenden Frequenz innerhalb eines Fensters vorhanden sind, die eine sichere Detektion erlauben. Problematischer ist die Darstellung von Transienten[22], die unter Umständen nur einmal innerhalb eines Fensters auftreten. Im ungünstigsten Fall treten sie in den Randbereichen des Fensters auf und werden somit von der Fensterfunktion unterdrückt. Durch eineÜberlappung der Fenster können auch diese Signalanteile erkannt werden.

2.4.2 Überlappung von Fenstern

An den Randbereichen aller Fenster gehen die Werte der Koeffizienten gegen Null, was f ür nur dort auftretende, meist hochfrequente Signalanteile oder Transienten praktisch eine Tiefpass- Filterung bedeutet. ÜberlapptmanzweiFensterumdieHälfte ihrer Länge, analysiert man jedes Sample doppelt und nimmt eine Gewichtung jedes Samples mit zwei unterschiedlichen Faktoren vor. Die Detektion von hohen Frequenzen, insbesondere von Transienten verbessert sich dadurch erheblich.

Da die geläufigen Fenstertypen symmetrisch sind, addieren sie sich bei einer Überlappung um 50% jeweils zu 1[23], sodass keine weitere Gewichtung des Signals erforderlich ist. Bei einer ÜberlappungumandereWertealsdiehalbeFensterlänge müssen die Ergebnisse entsprechend der Fensterfunktion gewichtet werden.

Die Wahl der Fenstergröße bedeutet demnach immer einen Kompromiss zwischen Zeit- und Frequenzauflösung. Dieser Kompromiss kann durch geschickte Wahl der Fensterart unter Beibehaltung der Frequenzauflösung zugunsten der Zeitauflösung ausfallen.

2.5 Eigenschaften von LPC und FFT im Vergleich

Die durch LPC oder FFT erzeugten Spektren unterscheiden sich grundlegend in ihren Eigenschaften, nicht jedoch in der Lage von markanten Spitzen. Tabelle 2.2 fasst die Eigenschaften von LPC und FFT zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Eigenschaften von FFT und LPC im Vergleich

Die LPC erzeugt ein an das Signal adaptiertes Filter, dessen Frequenzgang dargestellt wird. Daraus ergibt sich bei weniger komplexen Signalen ein erheblicher Genauigkeitsgewinn, weil die Auflösung des Filters nur von den Maxima der Einhüllenden des Spektrums bestimmt wird. Es können also die zur Verfügung stehenden Koeffizienten die wenigen Maxima detailliert darstellen. Im Gegensatz hierzu bleibt die Auflösung der FFT unabhängig von der Komplexität des Signals gleich.

Die Frequenzauflösung der FFT ist über das gesamte Spektrum konstant. So können zwei Schwingungen, deren Differenzfrequenz unter dieser Auflösung liegt, nicht getrennt dargestellt werden. Die getrennte Darstellung dieser beiden Frequenzen ist für das LPC-Filter ohne weiteres möglich, wenn nicht in anderen Bereichen des Spektrums durch hohe Komplexität des Signals eine große Anzahl an Filterkoeffizienten benötigt wird.

Das durch die LPC erzeugte Filter stellt Maxima im Spektrum erheblich genauer dar als Minima, weil die nach einem autoregressiven Modell berechnete LPC lediglich einen Polstellenfilter erzeugt, dessen grundlegende Eigenschaft die Darstellung von Maxima ist. Minima im Spektrum können, wie in [Cad82, S. 908-909] dargestellt, nur durch eine hohe Anzahl an Polstellen oder durch ein Nullstellenfilter dargestellt werden.

Die Einhüllende oder auch Hüllkurve des Spektrums hat ebenfalls die Eigenschaft, sich auf die wesentlichen und energiereichen Maxima zu konzentrieren. Sie zeigt die Struktur des Spektrums an. Das Resultat der Berechnung der LPC ist ein Spektrum, dessen Interpretation aufgrund des reduzierten Informationsgehalts leichter fällt, als die eines durch die FFT erzeugten. Ist die

Anzahl der abzubildenden Maxima sehr hoch, kann es bei der LPC zu ihrer Unterdrückung oder auch Verschiebung kommen.

Im Gegensatz hierzu wird durch die FFT jedes Maximum und Minimum des Spektrums, das innerhalb der Genauigkeit liegt, angezeigt. In Verbindung mit dem Leckeffekt erzeugt dies ein unruhiges, aber unter Umständen korrekteres Bild der Frequenzzusammensetzung. Die Kom- plexität des Signals hat keinen Einfluss auf die Darstellung einzelner Frequenzanteile. Maxima werden im Rahmen der Frequenzauflösung an ihren korrekten Stellen im Spektrum abgebildet.

Zusammenfassend erleichtert die Glättung des Spektrums durch die LPC das Ablesen von musikalischen Informationen wie Tonhöhen oder Klangfarbe, weil das Spektrum auf die wesent- lichen Informationen, nämlich die Spitzen der Formanten und des Grundtons beschränkt wird. Mit zunehmender Koeffizientenanzahl wird die Genauigkeit der LPC hinreichend gut.

2.6 Sonagramm

Das Sonagramm ist eine Darstellung des Spektrums eines Signals über der Zeit, wobei die Am- plituden der Frequenzanteile durch Farbe oder Schwärzung aufgetragen werden. Es ermöglicht die Kombination der Vorteile der Zeit- mit denen der Spektraldarstellung, indem es die Änderung des Spektrums über die Zeit sichtbar und Verläufe einer bestimmten Gestalt[24] verfolgbar macht.

Ein Sonagramm, das Farben zur Darstellung der Amplituden verwendet, ist wesentlich leichter zu interpretieren als eines, das lediglich die Intensität einer Farbe zur Darstellung verwendet. Die genaue Abbildung von feinen Amplitudenabstufungen ist durch Färbung erheblich besser zu erreichen, weil die Wahrnehmung von Farb- und Helligkeitsinformationen kombiniert werden kann.

Aus einem Sonagramm lassen sich die Wörter, bzw. Silben eines Sprechers anhand charakteristischer Änderungen im Spektrum über die Zeit erkennen, ohne das Signal zu hören. Gleiches gilt für die Erkennung von Tonhöhe und Rhythmus bei Musiksignalen. Die Erkennung von Musikinstrumenten, Klangfarbe und Dynamik ist, wenn auch mit beträchtlichem Aufwand und Training, ebenso durchführbar.

Aus tontechnischer Sicht stellt das Sonagramm eine sinnvolle Ergänzung zum aufmerksamen Hören dar, weil z.B. durch Maskierungseffekte des Gehörs bestimmte Frequenzanteile nicht wahrgenommen werden, diese aber im Sonagramm erscheinen.

Als künstlerisches Mittel bietet das Sonagramm direkte Rückkopplung über die Veränderungen in der Frequenzzusammensetzung eines Signals. Durch geeignete Manipulation in der Klangerzeugung kann das Sonagramm direkt deren Effekte darstellen.

3 Beschreibung der Software

Bei der Implementierung des Programms wurde großen Wert auf plattformübergreifende Standards gelegt. Sämtliche verwendeten Bibliotheken sind frei verfügbar und wie SonaSound auf einer großen Anzahl von Unices kompilierbar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Screenshot von SonaSound

In Abbildung 3.1 ist ein Screenshot von SonaSound unter Linux zu sehen. Die Oberfläche ist in ein Anzeigefenster und ein Einstellungs- und Kontrollfenster aufgeteilt. Den größten Teil des Anzeigefensters nimmt die Sonagramm-Darstellung ein, weil diese den größten Informationsgehalt hat.

Im Kontrollfenster sind alle Einstellmöglichkeiten des Programms und die Ablaufkontrolle platziert, um einen direkten Zugriff auf sämtliche Funktionen zu erhalten. Der untere Bereich des Fensters zeigt eine Zusammenfassung der aktuellen Einstellungen an und setzt diese zueinander ins Verhältnis.

Die folgenden Abschnitte erläutern die Voraussetzungen (Abschnitt 3.1) für den erfolgreichen Betrieb und die Kompilation (Abschnitt 3.1.5 auf Seite 22) von SonaSound. Wie die i n Abschnitt aufgestellten Zusammenhänge in der Software realisiert wurden beschreibt Abschnitt 3.5 auf Seite 32.

Des Weiteren werden sämtliche Funktionalitäten und einstellbare Parameter des Programms in Abschnitt 3.2 auf Seite 24 erläutert.

3.1 Voraussetzungen

In dieser Arbeit wurde eine natives, portables Programms zur Audioanalyse auf StandardHardware entwickelt. Im nächsten Abschnitt werden die Voraussetzungen auf Hard- und Softwareseite ausgeführt und die verwendeten Testsysteme beschrieben.

3.1.1 Hardwarevoraussetzungen

SonaSound ist auf momentan verfügbaren Standardrechnern jeder Art sicher lauffähig. Bei Systemen, die älter als zwei Jahre sind, ist es nur unter Beachtung der unter 3.1.2 gesammelten Erfahrungen in Echtzeit betreibbar.

Allgemeine Voraussetzungen

Eine flüssige Darstellung der Daten in Echtzeit erfordert einen relativ schnellen Rechner[1] mit einer beliebigen Soundkarte[2] und einer hochwertigen Grafikkarte[3]. Die Architektur des Rechners (PC, Mac, SUN, . . . ) spielt keine Rolle.

Selbstverständlich kann das Programm durch Heraufsetzen der Puffergröße, die direkt die Bildwiederholrate beeinflusst, oder Heruntersetzen der Analysegenauigkeit auch auf langsameren Systemen eingesetzt werden.

3.1.2 Konfiguration der Testsysteme

Das Programm wurde auf mehreren der Tabelle 3.1 auf der nächsten Seite zu entnehmenden Systemen entwickelt und getestet. Das Hauptentwicklungssystem wurde unter Linux auf IntelBasis betrieben.

Sämtliche Testsysteme sind Originalkonfigurationen oder, im Falle der PC-Hardware, aus Standard-Komponenten zusammengestellt. Die verwendeten Sound- und Grafikkarten sind mit

Ausnahme der USB-Soundkarte

”EMI[2]|[6]“vonEmagicgünstigeStandardkomponenten[4].Die

Betriebssysteme wurden abgesehen von den benötigten Bibliotheken nicht mit speziellen Zu- satzprogrammen versehen. Lediglich die korrekte Installation und Konfiguration der Grafikkar- tentreiber wurde genau beachtet. Mac OS X stellt eine geringfügige Ausnahme dar, wobei die verwendeten Zusatzprogramme nicht zum Betrieb SonaSounds benötigt werden. Die Software fink stellt lediglich eine unkomplizierte Installationsroutine für die Bibliotheken zur Verfügung.

Generell resultiert die Verwendung von gcc[5] in der Version 3.2 oder höher in erheblich schnel- lerem Code, da dieser Compiler in der Lage ist, prozessorspezifische Instruktionen (MMX, SSE,

Abbildung in dieser Leseprobe nicht enthalten

3DNOW, Altivec, . . . ) zu erzeugen, ohne dass Assembler-Code verwendet werden muss[6]. Es ist weiterhin zu bemerken, dass die Erzeugung prozessorspezifischer Optimierungen durch den gcc unter Linux auf Intel-Basis deutlich besser unterstützt wird, als auf PowerPC-Hardware. Dies ist auf die wesentlich weitere Verbreitung von PC-Hardware und die damit verbundene größere Entwicklerbasis zurückzuführen.

Ein Test des icc[7]-Compilers von Intel konnte eine Steigerung der Geschwindigkeit des Pro- gramms[8] um 30% verzeichnen. Dies ist in erster Linie auf die Fähigkeit dieses Compilers zurück- zuführen, Code zu vektorisieren[9] und in entsprechende Prozessorerweiterungen umzusetzen.

Die Qualität der Grafikkartentreiber und der Karten selbst ist ein wesentlicher Faktor für die Ausführungsgeschwindigkeit des Programms. Wie der Tabelle 3.1 zu entnehmen ist, sind die Treiber unter Mac OS X ab Version 10.2.3 qualitativ besser, da auf den entsprechenden Systemen eine geringere Prozessorleistung ausreicht, das Programm in Echtzeit zu betreiben. Die Systemlast durch große Speicherbewegungen ist unter Mac OS X höher als unter Linux, wird durch die höhere Qualität der Grafikkartentreiber aber ausgeglichen. Andere Faktoren, wie die mangelhafte Integration von X11 in die Aqua[10]-Oberfläche stellen hier aber ein Hindernis in der Benutzung dar.

Bei der Verwendung von Linux auf denselben PowerPC-Rechnern lässt die GrafikkartentreiberGeschwindigkeit etwas nach, wird aber durch die erheblich bessere Ausnutzung der sonstigen Ressourcen ausgeglichen.

Die Eignung bestimmter Grafikkartenmodelle für SonaSound lässt sich nur insoweit allgemein formulieren, als dass eine größerer Grafikkartenspeicher die Möglichkeit des hardwarebeschleunigten Blittings[11] auch bei weniger optimierten Treibern zulässt. Generell sollte ab einer Grafikspeichergröße von 64MByte die OpenGL-Unterstützung für hardwarebeschleunigtes Blitting[12] vorhanden sein. Bei geringeren Speichergrößen reservieren die meisten Grafikkartentreiber mehr Speicher für die Verwendung durch Texturen[13]. Deshalb wurde die Funktion zur SonagrammDarstellung (s. 3.5.2.3 auf Seite 44) in zwei verschiedenen Varianten implementiert. Es empfiehlt sich, Grafikkartenmodelle zu verwenden, die im Zusammenspiel mit ihren Treibern möglichst viel Grafikspeicher für die zweidimensionale Bearbeitung[14] reservieren.

Für die flüssige Darstellung einer Analyse im 24-Bit Grafikmodus, mit einer Abtastrate von 44,1kHz, einer Puffergröße von 2048 Samples und 128 LPC-Koeffizienten, die mit 4096 FFT- Punkten dargestellt werden, reichen alle Testsysteme aus, die einen Prozessortakt von 500MHz

3.1.3 Verwendete Software und Bibliotheken

Die Auswahl der Bibliotheken erfolgte nach folgenden Gesichtspunkten:

- Die Bibliotheken müssen frei[16] verfügbar sein und ihre Verbreitung sollte so weit fortgeschritten sein, dass davon auszugehen ist, dass sie im Lieferumfang eines aktuellen UnixDerivats enthalten sind oder einfach hinzugefügt werden können.
- Die Portabilität der Bibliotheken muss gewährleistet sein.
- Die Geschwindigkeit der enthaltenen Funktionen muss den Echtzeitansprüchen SonaSounds entsprechen.
- Die Nutzerfreundlichkeit für den Entwickler stellt ein schwaches Argument für oder gegen eine Bibliothek dar. Wichtiger ist jedoch die Benutzerfreundlichkeit der Bibliotheken des GUI für den Endbenutzer.

Bibliotheken, deren Verfügbarkeit unter einem Betriebssystem immer vorausgesetzt werden kann, werden im folgenden nicht aufgeführt. Dazu gehören unter anderem die Mathematik-Bibliothek und die Routinen zum Lesen und Schreiben von Dateien.

Unix

SonaSound ist ISO C99-kompatibel geschrieben, sodass eine Übersetzung des Programms mit jedem ISO-C-Compiler auf entsprechenden Systemen möglich ist.

Die verwendete Bibliothek(GTK) zur Generierung des GUI ist zwar nicht nur unter dem X-Window-System lauffähig, aber für dieses entwickelt worden. X11 gehört immer zum Lieferumfang eines Unix-Systems. Somit ist ein reibungsloser Betrieb SonaSounds momentan nur unter Unix-Derivaten sichergestellt.

Mac OS X ist erst ab Version 10.2.3 für die Verwendung zu empfehlen, da seit dieser Version das von Apple gelieferte X11 lauffähig ist. Unter XDarwin oder anderen X-Servern unter Mac OS X ist leider keine hardwarebeschleunigte Grafikausgabe zu erreichen, womit deren Verwendung für SonaSound so gut wie ausschlossen ist[17].

Die Entscheidung Unix zu verwenden, liegt in der Tatsache begründet, dass die Erstellung quelloffener Programme unter dieser Klasse Betriebssysteme am besten unterstützt wird, und die Stabilität und Flexibilität bei weitem über der von MS-Windows oder Mac OS 9 liegt.

Die Verwendung von Kerneln, die eine sehr niedrige Latenz unterstützen oder eine Echtzeit- verarbeitung erlauben, ist nur unter Unix, insbesondere Linux[18], einfach zu realisieren. Des Weiteren besitzen Unices immer die Möglichkeiten mehrere Prozesse gleichzeitig zu betreiben und ihnen verschiedene Prioritäten zuzuordnen, die nicht vom Fokus der grafischen Oberfläche abhängen.

Die verwendeten Bibliotheken verwenden alle das X-Window-System für die Anzeige auf dem Bildschirm. Unter Unix-Systemen ist dies der Standard, sodass diese Voraussetzung immer erf üllt sein wird. Allerdings unterscheidet sich die Unterstützung für direkten Grafikhardwarezugriff, den OpenGL benötigt, zwischen den X11-Hauptversionen beträchtlich. Von einer Verwendung von XFree86 in einer Version unter 4 ist abzuraten, da dort kein direkter Hardwarezugriff möglich ist.

Die meisten kommerziellen[19] XServer implementieren eine Form der Hardwarebeschleunigung für OpenGL, sodass in diesem Fall keine besonderen Vorkehrungen zu treffen sind. Die Verwendung von XFree86 für SonaSound erfordert das reibungslose Funktionieren der glx-Erweiterungen und die Unterstützung für DRI[20].

GimpToolKit

Das GimpToolKit[21] mit der zugrundeliegenden GLib wird zur Erzeugung sämtlicher Fenster und zur Verwaltung eines großen Teils der globalen Variablen (Adjustments) verwendet. Diese Bibliothek ist unter Unix weit verbreitet, weil sie dem GNOME-Desktop[22] zugrunde liegt, aber auch ohne diesen verwendbar ist. Die Benutzerfreundlichkeit eines GTK-basierten Programms ist sehr hoch, weil alle denkbaren Arten der Oberflächengestaltung implementierbar sind. Im Gegensatz zu der ebenso weit verbreiteten QT[23]-Bibliothek zeichnet sich GTK durch eine höhere Geschwindigkeit und weniger Lizenzungereimtheiten[24] aus.

Gtkglarea

Als Erweiterung zu GTK ermöglicht diese Bibliothek den direkten Aufruf von OpenGL-Befehlen innerhalb eines GTK-Fensters und die Verwendung von verschiedenen grafischen Kontexten innerhalb eines GTK-Fensters.

OpenGL

OpenGL ist eine von SGI[25] entwickelte plattformübergreifend verfügbare Bibliothek, die einen hardwarebeschleunigten Grafikkartenzugriff innerhalb einer relativ einfachen API[26] ermöglicht. Auch auf nicht direkt unterstützten Grafikkarten besteht mittels Software-Rendering[27] auf die Funktionen der Bibliothek Zugriff. Diese Software-Emulation nicht in der Hardware vorhandener Funktionen ermöglicht die einfache Implementation eines portablen Programms, wenn man die heutige Rechenleistung eines Mittelklassesystems in Betracht zieht.

OpenGL ist praktisch auf jedem Betriebssystem implementiert und frei verfügbar.

GLU

Das OpenGL-Utility-Toolkit vereinfacht viele OpenGL-Aufgaben und ist immer im Lieferumfang von OpenGL enthalten.

FFTW

Die ”Fastest Fourier Transform in the West“stellt sehr schnelle FFT-Funktionen für sämtliche Unix-Plattformen zur Verfügung und ist einfach bedienbar. Für einige Plattformen (K[6] und K[7] von AMD, Pentium von Intel und SPARC von SUN) existieren auch in Assembler optimierte Versionen der FFTW. Die Version [2] der Bibliothek ist frei verfügbar, aber nicht unter der GPL lizenziert. Mit Version [3] wird die FFTW unter der GPL stehen.

PortAudio

PortAudio ist eine von Ross Bencina und Phil Burk entwickelte portable Echtzeit-Audio- Bibliothek. Sie ist Callback-orientiert. d.h. zu jedem Zeitpunkt in Abhängigkeit von der gewählten Puffergröße, an dem neue Audiodaten zum Abspielen benötigt werden oder Audiodaten zur Verarbeitung anstehen, wird eine so genannte Callback-Funktion[28] aufgerufen, der die Audiodaten übergeben werden bzw. die Audiodaten liefert.

Die Verwendung dieser Bibliothek ermöglicht die Kompilation eines Programms auf sehr vielen Betriebssystemen, ohne dass der Programmierer die Einzelheiten der Soundkarten oder Treiberarchitektur beachten muss.

Unter Unix verwendet PortAudio Threads[29] zur flüssigen Bearbeitung der Audiodaten. Somit ist die pthreads-Bibliothek ebenso Voraussetzung zum erfolgreichen Betrieb von SonaSound. Diese Bibliothek sollte aber auf jedem Unix vorhanden sein.

PortAudio besteht aus drei Threads, die sich gegenseitig überwachen, um eineÜberlastung des Rechners zu verhindern. Der erste Thread ist der mit niedrigster Priorität läuft und vom ”canaryinthecoalmine“-Thread,der überwacht wird. Kann der ”watchdog“-Thread,dermithöchsterPrioritätläuft, ”canaryinthecoalmine“-Threadnichtmehrrechtzeitigausgeführt werden, wird der Audio-Thread, dessen Priorität zwischen den beiden liegt, vom Thread in der Priorität heruntergeregelt.

”watchdog“-

Lizenziert wird PortAudio unter einer freien Lizenz, die eine freie Verbreitung, Modifikation und Nutzung der Bibliothek erlaubt.

LibSndFile

LibSndFile ist eine von Erik de Castro Lopo geschriebene portable Bibliothek zum Lesen und Schreiben der meisten Audiodateiformate. Die Bibliothek steht unter der GPL. Durch ihre Ver- wendung ist SonaSound in der Lage, sämtliche verbreiteten Audio-Dateiformate zu lesen.

3.1.4 Verwendete Werkzeuge

Zur Übersetzung von SonaSound ist die Standard GNU-Suite an Werkzeugen erforderlich: Au- toconf und Automake erstellen ein configure-Skript, falls direkt von cvs[30]-Quellen kompiliert werden soll. In den Quellcode-Ausgaben von SonaSound ist dieses configure-Skript bereits ent- halten und Autoconf ist nicht erforderlich. Als Compiler wird gcc in Version 3.2 oder neuer empfohlen, obwohl erfolgreiche Kompilationen auch mit anderen Compilern durchgef ührt wur- den.

Für Linux-Distributionen ist darauf zu achten, dass die zu den Bibliotheken gehörigen Entwicklerpakete ebenfalls installiert werden.

Unter Mac OS X ist die Installation der kostenlos erhältlichen ”Developer-Tools“vonnöten,um einen Compiler und die zugehörigen Werkzeuge zur Verfügung zu stellen. Des Weiteren empfiehlt sich die Installation der Software fink[31], um die im vorigen Abschnitt genannten Bibliotheken einfach und unkompliziert installieren zu können.

Für die hier dokumentierte Entwicklung wurde für SonaSound auf der Webseite Source- Forge.Net[32] ein Account eingerichtet, über den Versionskontrolle, Release-Verwaltung, Bug- Reports, Webseite, Dokumentation, . . . abgewickelt werden. Die Adresse für den Zugriff auf dieses System lautet: http://sonasound.sourceforge.net.

Zusätzliche Software

Im Implementierungsprozess von SonaSound wurden sämtliche numerischen Tests und die Erprobung von Algorithmen mit der Software octave[33] durchgeführt. Debugging und Profiling der Software erfolgten über gdb und gprof. Somit wurde die gesamte Implementation des Programms nur mit quelloffener und frei verfügbarer Software realisiert.

3.1.5 Kompilation des Programms

Im Normalfall eines Standard-Unix-Systems sollte nach Installation aller oben genannten Bibliotheken das configure-Skript ohne Probleme alle Einstellungen erkennen und ein entsprechendes Makefile erzeugen, sodass die übliche Folge:

Abbildung in dieser Leseprobe nicht enthalten

eine erfolgreiche Installation ermöglicht. Weiterführend können dem configure-Skript zusätzlich zu den normalerweise unterstützten[34] noch folgende Optionen übergeben werden:

- --with-fftw=PFX

(Prefix zur FFTW-Bibliothek)

- --with-portaudio=PFX (Prefix zu PortAudio)

- --with-sndfile=PFX (Prefix zur LibSndFile)

- --enable-fast-ga

schaltet die Unterstützung für Blitting anstelle von Texturen an (Unter Mac OS X ist dies immer aktiviert)

Das configure-Skript und die Makefiles lassen sich sowohl mit Autoconf-2.1.x und Automake- 1.4, als auch mit den neuesten Versionen 2.5.x und 1.7 bearbeiten. Zur Neugenerierung des configure-Skripts aus configure.in ist allerdings mindestens Autoconf Version 2.5.x nötig. Es wird dringend empfohlen, SonaSound mit einem gcc in der Version 3 oder höher zu über- setzen, weil dieser Compiler eine erhebliche Geschwindigkeitssteigerung gegen über früheren Ver- sionen erzielen kann.

Compiler-Optionen

Im Folgenden werden nach Prozessortypen geordnet einige Optionen genannt, die ein direkt ausführbares Programm erzeugen, das die vorhandenen Ressourcen optimal ausnutzt. Grundle- gende Optimierungsschalter werden automatisch im configure-Skript gesetzt. Dazu gehört vor allem die Option

”-O[3]“unddasEntfernenderOption ”-g“,dieDebug-Informationenerzeugt.

Das Skript stellt weiterhin fest, um welchen CPU-Typ es sich handelt und versucht, plattform-

spezifische Optimierungen zu aktivieren. So wird auf G[4]-Prozessoren die Option

”-mcpu=[7400]

-maltivec -mabi=altivec“ gesetzt, um den Compiler anzuhalten, Altivec-Instruktionen zu erzeugen. Die Geschwindigkeit der Software wird auf G[3]-Prozessoren mittels der Optionen

”-mmultiple“, ”-mpowerpc-gfxopt“und ”-mcpu=[750]“erhöht.

Auf Intelplattformen wird die Existenz spezifischer Erweiterungen getestet und im Falle eines gcc in der Version [3] oder höher werden entsprechende Optionen zugeschaltet:

[...]


[1]Digitale Signalprozessoren: Auf die schnelle Verarbeitung von Signalen spezialisierte Prozessoren.

[2]Single Instruction Multiple Data: Mit einem Befehl können mehrere Datenworte (z.B. 4 · 32 = 128 Bit) auf einmal bearbeitet werden. Diese Funktionalität war bisher nur in DSPs zu finden.

[3]Die bisherigen Prozessorerweiterungen wie MMX und 3DNow beschleunigten lediglich die Verarbeitung von ganzen Zahlen (Integers)

[4]Die Dateiendung mp3 steht für eine Audiokompression nach dem Standard MPEG-1 Layer 3

[5]Als Unix-Derivate werden Betriebssysteme bezeichnet, die zur Klasse der auf Unix basierenden Systeme gehören: Dazu gehören Linux, FreeBSD, Solaris und viele andere.

[6]GNU General Public License (Siehe http://www.gnu.org).

Zitate von URLs reflektieren den Stand vom 01.04.2003 und können u.U. nicht mehr gültig sein.

[7]Die Ausführungsgeschwindigkeit anderer Programme wird durch die Verwendung SonaSounds nicht in störendem Maße gesenkt.

[8]Bundesministerium für Forschung und Technik.

[9]Echtzeit bedeutet in dieser Arbeit immer: synchron zu den Audiodaten. Also ausreichend schnell, um die Bearbeitung der aktuellen Daten bei Eintreffen der nächsten Daten abgeschlossen zu haben

[10] Nativ bedeutet, dass das Programm nur die im System verfügbaren Prozessoren verwendet.

[11] Graphical User Interface (Grafische Benutzeroberfläche)

[12] Central Processing Unit (Zentraler Prozessor eines Rechners)

[13] MS-Windows-spezifisches C++ und DSP56000-Routinen in [Vei99] bzw. MS-DOS-basierter Code mit hardwarespezifischer Grafikausgaberoutine in [Kle94].

[1]Bei Erreichen des Endes des Puffers werden die Daten am Anfang des Puffers mit den neuen Daten überschrieben. Der zusätzliche Aufwand der Zeiger-Verwaltung ist im Vergleich zum Geschwindigkeitsgewinn durch den Wegfall eines großen Kopiervorgangs im Speicher gering.

[2]Quantisierungsfehler treten durch Rundung eines Werts auf den nächsten darstellbaren Wert auf. Auch bei der Weiterverarbeitung von computergenerierten Signalen ist das Auftreten von Quantisierungsfehlern nicht auszuschließen, weil Ergebnisse einer komplexen Berechnung durchaus gerundet werden müssen.

[3]Diese Begrenzung besteht sowohl in festen oberen und unteren Grenzen des darstellbaren Zahlenbereichs, als auch in einer Begrenzung der erzielbaren Genauigkeit innerhalb des Zahlenbereichs.

[4]Länge des digitalen Worts, das die Amplitude eines Abtastwerts beschreibt, z.B. 16 Bit. [5]Häufigkeit der zeitlichen Abtastung des analogen Signals, z.B. 44,1kHz.

[6]Anzahl der durch digitale Worte darstellbaren Unterschiede zwischen Vollaussteuerung und Stille.

[7]Differenz zwischen höchster und niedrigster übertragener Frequenz. Die höchste darstellbare Frequenz ist immerFs/2.

[8]Seien sie direkt von einem Datenträger wie z.B. einer CD kopiert oder computergeneriert.

[9]Dazu sind wie bei Filmen mindestens 25 Bilder pro Sekunde vonnöten. Diese Anzahl wird auf einem Bildschirm oft noch nicht als flimmerfrei wahrgenommen.

[10] Abhängig von Puffergröße und Abtastrate.

[11] Jean Baptiste Joseph de Fourier stellte die Fourierreihe 1807 dar. Seine Arbeit geht unter anderem bis auf die Theorie der harmonischen Zusammensetzung der Klänge von Pythagoras zurück.

[12] Eine Multiplikation im Zeitbereich entspricht einer Faltung im Frequenzbereich und umgekehrt. [OS99, S. 60-61]

[13] Zeropadding bedeutet das Auffüllen einer Datenreihe mit Nullen, bis die gewünschte Länge erreicht ist.

[14] Da dies in den seltensten Fällen von Musik der Fall sein wird, tritt der Leckeffekt immer auf.

[15] Die Glottis bezeichnet die Stimmlippen bzw. -bänder.

[16] AutoRegressive Moving Average (Autoregressiver gleitender Mittelwert)

[17] z.B. partielle Korrelation, Singulärwertzerlegung oder Selective Linear Prediction.

[18] Dies bedeutet, dass r(i, k) = r(i + 1, k + 1) für 1 ≤ i ≤ M und 1 ≤ k ≤ M gilt.

[19] Die Impulsantwort eines digitalen Filters entspricht der Summe seiner Koeffizienten.

[20] e−ja = cos(a) − j sin(a) u M M M M ∞ 2.4 Fensterung 2 Grundlagen

[21] Engl.: Bins. Siehe [SS02], [OS99] u.v.a.

[22] kurze, sehr schnelle Amplitudenänderungen.

[23] Mit Ausnahme des Rechteckfensters, das über seinen gesamten Verlauf den Wert 1 besitzt.

[24] z.B. von Formanten

[1]Genaue Zahlen sind Tabelle 3.1 auf der nächsten Seite zu entnehmen. Prinzipielle Mindestvoraussetzung ist 500MHz Taktrate der CPU. Bei Multiprozessorsystemen kann diese Zahl geringer ausfallen.

[2]Je nach gewünschter Qualität der Analyse muss die Soundkarte ausgewählt werden. [3]Solide hochperformante Treiber und mindestens 8MB Grafikkartenspeicher.

[4]Auf den Macintosh-Systemen konnte nicht immer der eingebaute Soundchip verwendet werden, weil dieser auf den neueren Rechnern keinen Aufnahmekanal mehr zur Verfügung stellt. Hier wurde die USB-Soundkarte verwendet.

[5]GNU C-Compiler

[6]Selbstverständlich erreicht diese Form der Optimierung nicht die Geschwindigkeit selbst geschriebenen Assembler- Codes.

[7]Intel C-Compiler

[8]Natürlich nur des signalverarbeitenden Teils des Programms. Die Grafikausgabe kann nur durch eine Rekompilation der entsprechenden Bibliotheken mit dem icc beschleunigt werden.

[9]D.h. Schleifen durch SIMD-Instruktionen zu verkürzen.

[10] Aqua heißt die Bibliothek der nativen Oberfläche unter Mac OS X.

[11] Blitting bezeichnet das Verschieben eines rechteckigen Bereichs innerhalb eines Fensters an einen anderen Punkt in demselben Fenster. Dieser Prozess sollte normalerweise mit Kopierbewegungen innerhalb des Grafikkartenspeichers auskommen.

[12] Dieses ist über configure-Optionen (s. Abschnitt 3.1.5 auf Seite 22) beim Kompilieren einzustellen.

[13] Eine Textur stellt beliebige Bilddaten auf einem OpenGL-Objekt dar. Dadurch können Oberflächen von Objekten beliebige Eigenschaften erhalten (z.B. Mauersteine oder Teppichmuster).

[14] In den letzten Jahren wurden wenige Verbesserungen der 2D-Leistung von Grafikkarten erzielt. Die Hersteller konzentrieren sich auf die Erhöhung der 3D-Leistung. Dies kommt der 2D-Leistung nicht automatisch zugute.

[15] In erster Linie ist dies mit der höheren Fließkomma-Rechenleistung zu begründen. Im Falle des SPARC-Testsystems natürlich auch mit der Anzahl der Prozessoren.

[16] Frei im Sinne von kostenlos ist keine Voraussetzung. Frei meint, im Quellcode verfügbar und frei modifizierbar.

[17] Mit einem Mehrprozessorsystem ist genügend Rechenleistung für die hauptprozessorbasierte Grafikausgabe vorhanden. Diese Art von PowerPC-System stand aber nicht zur Verfügung, um dies für Macintosh-Systeme bestätigen zu können.

[18] Bei anderen, meist kommerziellen, Unices hängt diese Unterstützung vom Hersteller ab, ist aber, wie im Falle von Mac OS X, oft bereits im Lieferumfang enthalten.

[19] Z.B. die von Silicon Graphics oder Sun gelieferten.

[20] Direct Rendering Infrastructure: http://dri.sourceforge.net

[21] Gimp (GNU Image Manipulation Program) ist ein Bildbearbeitungsprogramm, für das diese Bibliothek ursprünglich entwickelt wurde.

[22] GNOME steht für GNU Object Model Environment. Es ist eine von vielen Desktop-Umgebungen für Unix.

[23] QT ist eine von der Firma Trolltech entwickelte Bibliothek, die der KDE-Desktop-Umgebung zugrunde liegt.

[24] Die Lizensierung von QT durch die Firma Trolltech ist mehrschichtig und es muss immer sehr genau abgewogen werden, welche Anwendung erfolgen soll.

[25] Silicon Graphics Inc.

[26] Application Programmer’s Interface. Die API beschreibt die Schnittstellen einer Bibliothek, wird aber auch zur Bezeichnung der Bibliothek selbst verwendet.

[27] Die CPU des Rechners muss dann die Aufgaben der Grafikkarte miterfüllen.

[28] Callback-Funktionen werden ohne besondere Interaktion in Abhängigkeit eines Ereignis oder Signals aufgerufen.

[29] Threads sind Unterprozesse eines Hauptprogramms, die Daten miteinander teilen können, sich ansonsten aber wie zwei verschiedene Programme verhalten.

Details

Seiten
139
Jahr
2003
ISBN (eBook)
9783638277532
ISBN (Buch)
9783638702027
Dateigröße
1.8 MB
Sprache
Deutsch
Katalognummer
v25014
Institution / Hochschule
Technische Universität Berlin – Kommunikationswissenschaften
Note
Sehr gut
Schlagworte
Entwicklung Programms Unix Visualisierung Audiosignalen Spektralbereich

Autor

Teilen

Zurück

Titel: Entwicklung eines nativen Programms unter Unix zur synchronen Visualisierung von Audiosignalen im Spektralbereich