Kombiniertes Audiogeräte-Routing

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Die kombinierte Audiogeräte-Routing-Funktion fügt Unterstützung für das gleichzeitige Streamen von Audio an mehrere Audiogeräte hinzu. Mit dieser Funktion können privilegierte Apps über System-APIs mehrere bevorzugte Geräte für eine bestimmte Strategie auswählen. Apps können Funktionen von Audiogeräten genauer erkennen, indem sie die öffentlichen APIs verwenden, die von dieser Funktion bereitgestellt werden. Für Android-Versionen 11 und darunter bietet die Audio-Framework-Implementierung eingeschränkte Unterstützung für mehrere Audiogeräte desselben Typs (z. B. 2 Bluetooth A2DP-Headsets), die gleichzeitig verbunden sind. Die standardmäßigen Audio-Routingregeln erlauben Benutzern auch nicht, mehrere Geräte desselben Typs für einen bestimmten Anwendungsfall auszuwählen.

Ab Android 12 werden diese Einschränkungen aufgehoben, um neue Anwendungsfälle wie Audioübertragung, Multicasting an eine Gruppe von BLE-Audiokopfhörern oder die gleichzeitige Verwendung mehrerer USB-Soundkarten zu ermöglichen.

Auf dieser Seite erfahren Sie, wie Sie die Unterstützung für das Streamen von Audio auf mehrere Audiogeräte implementieren und wie Sie Ihre Implementierung dieser Funktion validieren.

Unterstützung von Audio-Streaming auf mehrere Audiogeräte

Es gibt zwei Gruppen von APIs in Android 12, die diese Funktion unterstützen:

  • Die System-APIs verarbeiten mehrere bevorzugte Geräte für eine Strategie.
  • Die vom Anbieter als Teil der Audio-HAL implementierte HIDL-Schnittstelle meldet Gerätefähigkeiten.

In den folgenden Abschnitten wird jede dieser APIs ausführlicher behandelt.

Umgang mit mehreren bevorzugten Geräten für eine Strategie

Der Audio Policy Manager bietet System-APIs, um das gleichzeitige Streamen von Audio auf mehrere Audiogeräte besser zu unterstützen. Diese System-APIs ermöglichen das Einstellen, Abrufen und Entfernen mehrerer bevorzugter Geräte für eine bestimmte Strategie. Bis Android 12 wurde diese Funktion nur für ein einzelnes Gerät unterstützt.

Der Audio Policy Manager führt das Konzept der aktiven Mediengeräte ein, um die Geräte zu beschreiben, die am wahrscheinlichsten für die Medienwiedergabe ausgewählt werden. Wenn ein abnehmbares Gerät angeschlossen ist, müssen die Audio-HAL-Ausgangsstreams, die an dieses Gerät geleitet werden können, möglicherweise geöffnet und auf unterstützte Attribute geprüft werden.

Beim Öffnen eines Ausgabestreams muss ein Audiogerät angegeben werden. Das aktive Mediengerät ist das Gerät, das verwendet wird, wenn Ausgabestreams in diesem Kontext geöffnet werden.

Die Auswahl des aktiven Mediengeräts kann sich abhängig von den tatsächlich angeschlossenen oder getrennten Geräten ändern. Der Audio Policy Manager verwendet die folgende Reihe von Regeln, um aktive Mediengeräte auszuwählen:

  1. Wenn alle bevorzugten Geräte für Medien verfügbar sind, werden sie alle als aktive Geräte ausgewählt.
  2. Andernfalls wird das zuletzt verbundene Wechselmedium ausgewählt.
  3. Wenn keine Wechseldatenträger angeschlossen sind, werden die standardmäßigen Audiorichtlinienregeln für die Auswahl von Ausgabegeräten auf die Auswahl aktiver Geräte angewendet.

Ein Ausgabestream muss die folgenden Kriterien erfüllen, um erneut geöffnet und an die aktiven Geräte weitergeleitet zu werden, damit die beste Konfiguration für die Wiedergabe ausgewählt wird:

  • Der Ausgabestream muss die aktiven Geräte unterstützen.
  • Der Ausgabestream muss dynamische Profile unterstützen.
  • Der Ausgangsstrom darf derzeit nicht an aktive Geräte geleitet werden.

Um eine neue Geräteauswahl anzuwenden, schließt der Audio Policy Manager einen Ausgabestream und öffnet ihn erneut, wenn eine Geräteverbindung besteht, wenn der Ausgabestream im Leerlauf ist, oder verzögert ihn, wenn der Ausgabestream in den Standby-Modus versetzt wird.

Der Audio Policy Manager bietet die folgende Liste von System-APIs (wie in AudioManager.java definiert):

  • setPreferredDeviceForStrategy

    Legt das bevorzugte Gerät für das Audio-Routing für eine bestimmte Strategie fest. Beachten Sie, dass das Gerät zum Zeitpunkt der Einstellung des bevorzugten Geräts möglicherweise nicht verfügbar ist, aber verwendet wird, sobald es verfügbar ist.

  • removePreferredDeviceForStrategy

    Entfernt die zuvor mit setPreferredDeviceForStrategy oder setPreferredDevicesForStrategy festgelegten bevorzugten Audiogeräte.

  • getPreferredDeviceForStrategy

    Gibt das bevorzugte Gerät für eine zuvor mit setPreferredDeviceForStrategy oder setPreferredDevicesForStrategy festgelegte Audiostrategie zurück.

  • setPreferredDevicesForStrategy

    Legt die bevorzugten Geräte für eine bestimmte Strategie fest.

  • getPreferredDevicesForStrategy

    Gibt die bevorzugten Geräte für eine zuvor mit setPreferredDeviceForStrategy oder setPreferredDevicesForStrategy festgelegte Audiostrategie zurück.

  • OnPreferredDevicesForStrategyChangedListener

    Definiert eine Schnittstelle zur Benachrichtigung über Änderungen in den bevorzugten Audiogeräten, die für eine bestimmte Audiostrategie eingestellt sind.

  • addOnPreferredDevicesForStrategyChangedListener

    Fügt einen Listener hinzu, um über Änderungen am von der Strategie bevorzugten Audiogerät benachrichtigt zu werden.

  • removeOnPreferredDevicesForStrategyChangedListener

    Entfernt einen zuvor hinzugefügten Listener von Änderungen am von der Strategie bevorzugten Audiogerät.

Gerätefunktionen melden

Als Teil der Audio-HAL-Implementierung implementieren Anbieter die APIs, die die Funktionen von Berichtsgeräten unterstützen. Dieser Abschnitt erläutert die Datentypen und Methoden, die zum Melden von Gerätefunktionen verwendet werden, und listet einige Änderungen auf, die in Audio HIDL HAL V7 vorgenommen wurden, um mehrere Geräte zu unterstützen.

Datentypen

In Audio HIDL HAL V7 werden Gerätefunktionen mithilfe der Strukturen AudioProfile und AudioTransport gemeldet. Die AudioTransport Struktur beschreibt die Fähigkeit eines Audioports mit AudioProfile für bekannte Audioformate oder mit rohen Hardwaredeskriptoren für Formate, die der Plattform nicht bekannt sind. Die AudioProfile Struktur enthält das Audioformat, die vom Profil unterstützten Abtastraten und die Liste der Kanalmasken, wie im folgenden Codeblock von types.hal :

/**
* Configurations supported for a certain audio format.
*/
struct AudioProfile {
   AudioFormat format;
   /** List of the sample rates (in Hz) supported by the profile. */
   vec<uint32_t> sampleRates;
   /** List of channel masks supported by the profile. */
   vec<AudioChannelMask> channelMasks;
};

In Audio HIDL HAL V7 wird der Datentyp AudioPort mit den Strukturen AudioTransport und AudioProfile definiert, um die Fähigkeiten des Geräts zu beschreiben.

Audio-HAL-Methoden

Der Audio Policy Manager verwendet die folgenden Methoden, um die Fähigkeiten des Geräts abzufragen:

  • getParameters: Eine generische Methode zum Abrufen herstellerspezifischer Parameterwerte wie unterstützter Audioformate und ihrer jeweiligen Abtastraten.
  • getAudioPort: Gibt die Liste der unterstützten Attribute (wie Abtastraten, Formate, Kanalmasken, Verstärkungsregler) für einen bestimmten Audioport zurück.

Der folgende Code aus IDevice.hal zeigt die Schnittstelle für die getAudioPort Methode:

   /**
    * Returns the list of supported attributes for a given audio port.
    *
    * As input, 'port' contains the information (type, role, address etc...)
    * needed by the HAL to identify the port.
    *
    * As output, 'resultPort' contains possible attributes (sampling rates,
    * formats, channel masks, gain controllers...) for this port.
    *
    * @param port port identifier.
    * @return retval operation completion status.
    * @return resultPort port descriptor with all parameters filled up.
    */
   getAudioPort(AudioPort port)
           generates (Result retval, AudioPort resultPort);

Änderungen an der Legacy-API

Um mehrere Audioprofile zu unterstützen, fügt Version 3.2 der Legacy-API eine neue Struktur namens audio_port_v7 . Weitere Details finden Sie im Quellcode .

Aufgrund der Hinzufügung von audio_port_v7 fügt Version 3.2 der Legacy-API eine neue API namens get_audio_port_v7 hinzu, um die Funktionen von Geräten mithilfe der audio_port_v7 Struktur abzufragen.

Der folgende Code aus audio.h zeigt die Definition der get_audio_port_v7 API:

/**
 * Fills the list of supported attributes for a given audio port.
 * As input, "port" contains the information (type, role, address etc...)
 * needed by the HAL to identify the port.
 * As output, "port" contains possible attributes (sampling rates,
 * formats, channel masks, gain controllers...) for this port. The
 * possible attributes are saved as audio profiles, which contains audio
 * format and the supported sampling rates and channel masks.
 */
 int (*get_audio_port_v7)(struct audio_hw_device *dev,
                          struct audio_port_v7 *port);

Daten aus der Legacy get_audio_port API müssen in das neue AudioPort -Format eingefügt werden, wenn die Legacy-API-Version unter 3.2 und die HIDL HAL-Version 7 oder höher ist. In diesem Fall wird davon ausgegangen, dass alle gemeldeten Abtastraten und Kanalmasken von get_audio_port für alle zurückgegebenen Formate unterstützt werden, was eine einfache Zuordnung von get_audio_port Werten zur neuen AudioPort -Struktur ermöglicht.

Beispiel-API-Implementierungen

In diesem Abschnitt werden mehrere Testsuiten beschrieben, die Methoden enthalten, die die in den vorherigen Abschnitten behandelten APIs verwenden. In diesen Methoden finden Sie einige Beispiele dafür, wie diese APIs implementiert und verwendet werden.

Ein Beispiel für die Verwendung der System-APIs setPreferredDevicesForStrategy , getPreferredDevicesForStrategy , removePreferredDeviceForStrategy und OnPreferredDevicesForStrategyChangedListener ist die Methode PreferredDeviceRoutingTest , die sich in GTS befindet.

Um ein Beispiel der neuen Struktur in AudioDeviceInfo in Gebrauch zu sehen, sehen Sie sich die Methode AudioManagerTest#testGetDevices , die sich in CTS befindet.

Ein Beispiel der Implementierung für get_audio_port_v7 befindet sich in audio_hal.c und zeigt, wie Fähigkeiten für mehrere Geräte abgefragt werden.

Validierung

Dieser Abschnitt enthält Informationen zur CTS- und GTS-Validierung (Google Mobile Services Test Suite) des Audio-Managers.

CTS-Tests

CTS-Tests befinden sich in android.media.cts.AudioManagerTest .

Im Folgenden finden Sie eine Liste der verfügbaren Audio-Manager-Tests:

  • AudioManagerTest#testGetDevices

    Überprüft die genauen Fähigkeiten des Audiogeräts. Außerdem wird überprüft, ob die zurückgegebenen Audioprofile in der AudioDeviceInfo Struktur den Inhalt des älteren, reduzierten Array-Formats beibehalten, aber im neuen AudioProfile -Format vorliegen.

  • AudioManagerTest#testPreferredDevicesForStrategy und AudioManagerTest#testPreferredDeviceForCapturePreset

    Stellen Sie sicher, dass die API-Tests mit den bevorzugten Geräten für Strategie und Erfassung erfolgreich abgeschlossen werden.

GTS-Tests

GTS-Tests befinden sich in com.google.android.gts.audioservice.AudioServiceHostTest .

Führen Sie die Tests AudioServiceHostTest#testPreferredDeviceRouting und AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset aus, um zu überprüfen, ob die APIs für bevorzugte Geräte für Strategie- und Erfassungsvorgaben richtig funktionieren.