Erste Schritte

Dieser Abschnitt enthält die Informationen, die für die ersten Schritte mit den OpenSL ES APIs erforderlich sind.

OpenSL ES zu Ihrer App hinzufügen

Sie können OpenSL ES sowohl mit C- als auch C++-Code aufrufen. Fügen Sie die Headerdatei OpenSLES.h ein, um Ihrer Anwendung den zentralen OpenSL ES-Funktionssatz hinzuzufügen: 

#include <SLES/OpenSLES.h>

Fügen Sie zum Hinzufügen der Android-Erweiterungen für OpenSL ES auch die Headerdatei OpenSLES_Android.h ein: 

#include <SLES/OpenSLES_Android.h>

Wenn Sie die Headerdatei OpenSLES_Android.h einfügen, werden die folgenden Header automatisch eingefügt: 

#include <SLES/OpenSLES_AndroidConfiguration.h>
#include <SLES/OpenSLES_AndroidMetadata.h>

Hinweis: Diese Header sind nicht erforderlich, werden aber als Hilfe beim Erlernen der API angezeigt.

Build erstellen und Fehler beheben

Sie können OpenSL ES in Ihren Build einbinden. Dazu geben Sie es in der Datei Android.mk an, die als Makefiles des NDK-Build-Systems dient. Fügen Sie Android.mk die folgende Zeile hinzu: 

LOCAL_LDLIBS += -lOpenSLES

Für eine zuverlässige Fehlerbehebung empfehlen wir, den SLresult-Wert zu prüfen, den die meisten OpenSL ES APIs zurückgeben. Sie können für die Fehlerbehebung Assertions oder eine erweiterte Fehlerbehandlungslogik verwenden. Keines von beiden bietet einen inhärenten Vorteil für die Arbeit mit OpenSL ES, obwohl eine der beiden Methoden für einen bestimmten Anwendungsfall besser geeignet ist.

In unseren Beispielen verwenden wir Assertions, da sie dazu beitragen, unrealistische Bedingungen abzufangen, die auf einen Codierungsfehler hinweisen könnten. Wir haben eine explizite Fehlerbehandlung für andere Bedingungen verwendet, die in der Produktion häufiger auftreten.

Viele API-Fehler führen neben einem Ergebniscode ungleich null zu einem Logeintrag. Solche Logeinträge können zusätzliche Details liefern, die sich bei relativ komplexen APIs wie Engine::CreateAudioPlayer als besonders nützlich erweisen.

Sie können das Protokoll entweder über die Befehlszeile oder in Android Studio aufrufen. Geben Sie Folgendes über die Befehlszeile ein, um das Log zu prüfen: 

$ adb logcat

Wenn Sie sich das Protokoll von Android Studio ansehen möchten, wählen Sie View > Tool Windows > Logcat (Ansicht > Tool-Fenster > Logcat) aus. Weitere Informationen finden Sie unter Logs mit Logcat schreiben und ansehen.

Beispielcode

Wir empfehlen, unterstützten und getesteten Beispielcode zu verwenden, der als Modell für Ihren eigenen Code verwendet werden kann. Er befindet sich in den Ordnern audio-echo und native-audio des GitHub-Repositorys android-ndk.

Achtung : Die Spezifikation von OpenSL ES 1.0.1 enthält im Anhang Beispielcode. Weitere Informationen finden Sie unter Khronos OpenSL ES Registry. In den Beispielen in Anhang B: Beispielcode und Anhang C: Beispielcode für den Anwendungsfall werden jedoch Funktionen verwendet, die von Android nicht unterstützt werden. Einige Beispiele enthalten auch typografische Fehler oder verwenden APIs, die sich wahrscheinlich ändern. Seien Sie vorsichtig, wenn Sie sich auf diese beziehen. Der Code kann zwar für das Verständnis des vollständigen OpenSL ES-Standards hilfreich sein, sollte aber nicht unverändert für Android verwendet werden.

Audio-Inhalt

Hier sind einige der vielen Möglichkeiten, wie Sie Audioinhalte für Ihre App verpacken können:

  • Ressourcen: Wenn du deine Audiodateien im Ordner res/raw/ abspeicherst, können sie über die zugehörigen APIs für Resources ganz einfach darauf zugreifen. Es gibt jedoch keinen direkten nativen Zugriff auf Ressourcen. Daher müssen Sie in Programmiersprache Java-Code schreiben, um die Ressourcen vor der Verwendung zu kopieren.
  • Assets: Wenn du deine Audiodateien im Ordner assets/ speicherst, können sie über die nativen Android Asset Manager APIs direkt darauf zugreifen. Weitere Informationen zu diesen APIs finden Sie in den Headerdateien android/asset_manager.h und android/asset_manager_jni.h. Der Beispielcode im GitHub-Repository android-ndk verwendet diese nativen Asset Manager APIs in Verbindung mit dem Android File Descriptor Data Locator.
  • Netzwerk: Mit dem URI Data Locator können Sie Audioinhalte direkt aus dem Netzwerk wiedergeben. Wir empfehlen dir jedoch, den Artikel Sicherheit und Berechtigungen zu lesen.
  • Lokales Dateisystem: Der URI-Datensucher unterstützt das Schema file: für lokale Dateien, sofern die Dateien für die Anwendung zugänglich sind. Beachten Sie, dass das Android-Sicherheitsframework den Dateizugriff über die Linux-Nutzer-ID- und Gruppen-ID-Mechanismen einschränkt.
  • Aufgezeichnet: Ihre App kann Audiodaten über die Mikrofoneingabe aufzeichnen, diese Inhalte speichern und später wiedergeben. Im Beispielcode wird diese Methode für den Wiedergabeclip verwendet.
  • Inline kompiliert und verknüpft: Sie können Audioinhalte direkt mit der gemeinsam genutzten Bibliothek verknüpfen und dann über einen Audioplayer mit einem Zwischenspeicher für Datensuche abspielen. Diese Option eignet sich am besten für kurze Clips im PCM-Format. Im Beispielcode wird diese Technik für die Clips Hello und Android verwendet. Die PCM-Daten wurden mit einem bin2c-Tool (nicht bereitgestellt) in Hexadezimalstrings konvertiert.
  • Echtzeit-Synthese: Ihre Anwendung kann PCM-Daten spontan synthetisieren und dann mit einem Audioplayer mit Zwischenspeicherdatensuche wiedergeben. Dies ist eine relativ fortgeschrittene Technik und die Details der Audiosynthese werden in diesem Artikel nicht behandelt.

Hinweis : Die Suche oder Erstellung nützlicher Audioinhalte für Ihre Anwendung wird in diesem Artikel nicht behandelt. Sie können in der Websuche Suchbegriffe wie Interaktive Audio, Spiel-Audio, Tondesign und Audioprogrammierung verwenden, um weitere Informationen zu finden.

Achtung:Sie müssen dafür sorgen, dass Sie gesetzlich dazu berechtigt sind, Inhalte wiederzugeben oder aufzuzeichnen. Bei der Aufzeichnung von Inhalten könnte der Datenschutz berücksichtigt werden.

Codebeispiele

Diese Beispiel-Apps sind auf unserer GitHub-Seite verfügbar:

  • audio-echo erzeugt eine Ein-/Ausgabe-Roundtrip-Schleife.
  • native-audio ist ein einfacher Audiorekorder/-player.

Die Android NDK-Implementierung von OpenSL ES unterscheidet sich in einigen Punkten von der Referenzspezifikation für OpenSL ES 1.0.1. Diese Unterschiede sind ein wichtiger Grund dafür, dass Beispielcode, den Sie direkt aus der OpenSL ES-Referenzspezifikation kopieren, möglicherweise nicht in Ihrer Android-App funktioniert.

Weitere Informationen zu den Unterschieden zwischen der Referenzspezifikation und der Android-Implementierung finden Sie unter OpenSL ES for Android.