Audio numérique USB

Cet article passe en revue la prise en charge d'Android pour l'audio numérique USB et les protocoles USB associés.

Public

Le public cible de cet article est constitué des OEM d'appareils Android, des fournisseurs de SoC, des fournisseurs de périphériques audio USB, des développeurs d'applications audio avancées et d'autres personnes cherchant une compréhension détaillée des composants internes de l'audio numérique USB sur Android.

Les utilisateurs finaux d'appareils Nexus doivent plutôt consulter l'article Enregistrer et lire de l'audio en mode hôte USB dans le centre d'aide Nexus . Bien que cet article ne soit pas destiné aux utilisateurs finaux, certains consommateurs audiophiles pourraient y trouver des éléments intéressants.

Présentation de l'USB

Universal Serial Bus (USB) est décrit de manière informelle dans l'article Wikipédia USB et est formellement défini par les normes publiées par USB Implementers Forum, Inc. Pour plus de commodité, nous résumons ici les concepts clés de l’USB, mais les normes font autorité.

Concepts de base et terminologie

L'USB est un bus avec un seul initiateur d'opérations de transfert de données, appelé hôte . L'hôte communique avec les périphériques via le bus.

Remarque : Les termes périphérique et accessoire sont des synonymes courants de périphérique . Nous évitons ces termes ici, car ils pourraient être confondus avec un appareil Android ou avec le concept spécifique à Android appelé mode accessoire .

Un rôle critique de l'hôte est l'énumération : le processus de détection des périphériques connectés au bus et d'interrogation de leurs propriétés exprimées via des descripteurs .

Un périphérique peut être un objet physique mais implémenter en réalité plusieurs fonctions logiques. Par exemple, un périphérique webcam pourrait avoir à la fois une fonction caméra et une fonction audio microphone.

Chaque fonction périphérique possède une interface qui définit le protocole pour communiquer avec cette fonction.

L'hôte communique avec un périphérique via un canal vers un point final , une source de données ou un récepteur fourni par l'une des fonctions du périphérique.

Il existe deux types de canaux : message et stream . Un canal de messages est utilisé pour le contrôle et l'état bidirectionnels. Un canal de flux est utilisé pour le transfert de données unidirectionnel.

L'hôte initie tous les transferts de données, c'est pourquoi les termes d'entrée et de sortie sont exprimés par rapport à l'hôte. Une opération d'entrée transfère les données du périphérique vers l'hôte, tandis qu'une opération de sortie transfère les données de l'hôte vers le périphérique.

Il existe trois principaux modes de transfert de données : interruption , masse et isochrone . Le mode isochrone sera discuté plus en détail dans le contexte de l'audio.

Le périphérique peut avoir des terminaux qui se connectent au monde extérieur, au-delà du périphérique lui-même. De cette façon, le périphérique sert à traduire entre le protocole USB et les signaux du « monde réel ». Les terminaux sont des objets logiques de la fonction.

Modes USB Android

Mode de développement

Le mode développement est présent depuis la version initiale d’Android. L'appareil Android apparaît comme un périphérique USB sur un PC hôte exécutant un système d'exploitation de bureau tel que Linux, Mac OS X ou Windows. La seule fonction périphérique visible est soit Android fastboot , soit Android Debug Bridge (adb) . Les protocoles fastboot et adb sont superposés au mode de transfert de données en masse USB.

Mode hôte

Le mode hôte est introduit dans Android 3.1 (API niveau 12).

Comme l'appareil Android doit agir en tant qu'hôte et que la plupart des appareils Android incluent un connecteur micro-USB qui ne permet pas directement le fonctionnement de l'hôte, un adaptateur on-the-go ( OTG ) tel que celui-ci est généralement requis :

Figure 1. Adaptateur On-the-Go (OTG)

Un appareil Android peut ne pas fournir suffisamment d'énergie pour faire fonctionner un périphérique particulier, en fonction de la quantité d'énergie dont le périphérique a besoin et de la quantité que l'appareil Android est capable de fournir. Même si une alimentation adéquate est disponible, la charge de la batterie de l'appareil Android peut être considérablement réduite. Pour ces situations, utilisez un hub alimenté tel que celui-ci :

Figure 2. Hub alimenté

Mode accessoire

Le mode accessoire a été introduit dans Android 3.1 (API niveau 12) et rétroporté sur Android 2.3.4. Dans ce mode, l'appareil Android fonctionne comme un périphérique USB, sous le contrôle d'un autre appareil tel qu'un dock qui sert d'hôte. La différence entre le mode développement et le mode accessoire réside dans le fait que des fonctions USB supplémentaires sont visibles par l'hôte, au-delà de l'adb. L'appareil Android commence en mode développement puis passe en mode accessoire via un processus de renégociation.

Le mode accessoire a été étendu avec des fonctionnalités supplémentaires dans Android 4.1, notamment l'audio décrit ci-dessous.

Audio USB

Cours USB

Chaque fonction périphérique est associée à un document de classe de périphérique qui spécifie le protocole standard pour cette fonction. Cela permet aux hôtes conformes à la classe et aux fonctions périphériques d'interagir, sans connaissance détaillée du fonctionnement de chacun. La conformité de classe est essentielle si l'hôte et le périphérique sont fournis par des entités différentes.

Le terme sans pilote est un synonyme courant de conforme à la classe , indiquant qu'il est possible d'utiliser les fonctionnalités standard d'un tel périphérique sans nécessiter l'installation d'un pilote spécifique au système d'exploitation. On peut supposer qu'un périphérique annoncé comme « aucun pilote requis » pour les principaux systèmes d'exploitation de bureau sera conforme à la classe, bien qu'il puisse y avoir des exceptions.

Cours audio USB

Ici, nous nous intéressons uniquement aux périphériques qui implémentent des fonctions audio et adhérons donc à la classe des périphériques audio. Il existe deux éditions de la spécification de classe audio USB : classe 1 (UAC1) et 2 (UAC2).

Comparaison avec d'autres classes

L'USB comprend de nombreuses autres classes de périphériques, dont certaines peuvent être confondues avec la classe audio. La classe de stockage de masse (MSC) est utilisée pour un accès sectoriel aux médias, tandis que le Media Transfer Protocol (MTP) est destiné à un accès complet aux fichiers aux médias. MSC et MTP peuvent être utilisés pour transférer des fichiers audio, mais seule la classe audio USB convient au streaming en temps réel.

Bornes audio

Les bornes d'un périphérique audio sont généralement analogiques. Le signal analogique présenté à la borne d'entrée du périphérique est converti en numérique par un convertisseur analogique-numérique (ADC) et est transporté via le protocole USB pour être consommé par l'hôte. L'ADC est une source de données pour l'hôte. De même, l'hôte envoie un signal audio numérique via le protocole USB au périphérique, où un convertisseur numérique-analogique (DAC) convertit et présente à un terminal de sortie analogique. Le DAC est un puits pour l'hôte.

Canaux

Un périphérique doté d'une fonction audio peut inclure un terminal source, un terminal récepteur ou les deux. Chaque direction peut avoir un canal ( mono ), deux canaux ( stéréo ) ou plus. Les périphériques comportant plus de deux canaux sont appelés multicanaux . Il est courant d'interpréter un flux stéréo comme étant constitué de canaux gauche et droit , et par extension d'interpréter un flux multicanal comme ayant des emplacements spatiaux correspondant à chaque canal. Cependant, il est également tout à fait approprié (en particulier pour l'audio USB, plus que pour le HDMI ) de ne pas attribuer de signification spatiale standard particulière à chaque canal. Dans ce cas, c'est à l'application et à l'utilisateur de définir comment chaque canal est utilisé. Par exemple, un flux d'entrée USB à quatre canaux peut avoir les trois premiers canaux connectés à différents microphones dans une pièce et le canal final recevant l'entrée d'une radio AM.

Mode de transfert isochrone

L'audio USB utilise le mode de transfert isochrone pour ses caractéristiques en temps réel, au détriment de la récupération sur erreur. En mode isochrone, la bande passante est garantie et les erreurs de transmission de données sont détectées à l'aide d'un contrôle de redondance cyclique (CRC). Mais il n’y a pas d’accusé de réception ni de retransmission des paquets en cas d’erreur.

Des transmissions isochrones ont lieu à chaque période de début de trame (SOF). La période SOF est d'une milliseconde à pleine vitesse et de 125 microsecondes à haute vitesse. Chaque trame à pleine vitesse transporte jusqu'à 1 023 octets de charge utile, et une trame à grande vitesse transporte jusqu'à 1 024 octets. En les regroupant, nous calculons le taux de transfert maximum à 1 023 000 ou 8 192 000 octets par seconde. Cela définit une limite supérieure théorique pour la fréquence d'échantillonnage audio combinée, le nombre de canaux et la profondeur de bits. La limite pratique est inférieure.

En mode isochrone, il existe trois sous-modes :

• Adaptatif
• Asynchrone
• Synchrone

En sous-mode adaptatif, le récepteur ou la source périphérique s'adapte à une fréquence d'échantillonnage potentiellement variable de l'hôte.

En sous-mode asynchrone (également appelé rétroaction implicite), le récepteur ou la source détermine la fréquence d'échantillonnage et l'hôte s'y adapte. Le principal avantage théorique du sous-mode asynchrone est que l'horloge USB source ou récepteur est physiquement et électriquement plus proche (et peut même être la même que, ou dérivée de) l'horloge qui pilote le DAC ou l'ADC. Cette proximité signifie que le sous-mode asynchrone devrait être moins sensible à la gigue d'horloge. De plus, l'horloge utilisée par le DAC ou l'ADC peut être conçue pour offrir une plus grande précision et une dérive plus faible que l'horloge hôte.

En sous-mode synchrone, un nombre fixe d'octets est transféré à chaque période SOF. La fréquence d'échantillonnage audio est effectivement dérivée de l'horloge USB. Le sous-mode synchrone n'est pas couramment utilisé avec l'audio car l'hôte et le périphérique sont à la merci de l'horloge USB.

Le tableau ci-dessous résume les sous-modes isochrones :

En pratique, le sous-mode est bien entendu important, mais d’autres facteurs doivent également être pris en compte.

Prise en charge Android pour la classe audio USB

Mode de développement

L'audio USB n'est pas pris en charge en mode développement.

Mode hôte

Android 5.0 (API niveau 21) et supérieur prend en charge un sous-ensemble de fonctionnalités USB audio classe 1 (UAC1) :

• L'appareil Android doit agir en tant qu'hôte
• Le format audio doit être PCM (interface type I)
• La profondeur de bits doit être de 16 bits, 24 bits ou 32 bits, 24 bits de données audio utiles étant justifiés à gauche dans les bits les plus significatifs du mot de 32 bits.
• La fréquence d'échantillonnage doit être de 48, 44,1, 32, 24, 22,05, 16, 12, 11,025 ou 8 kHz.
• Le nombre de canaux doit être 1 (mono) ou 2 (stéréo)

La lecture du code source du framework Android peut révéler du code supplémentaire au-delà du minimum nécessaire pour prendre en charge ces fonctionnalités. Mais ce code n’a pas été validé, donc des fonctionnalités plus avancées ne sont pas encore revendiquées.

Mode accessoire

Android 4.1 (API niveau 16) a ajouté une prise en charge limitée de la lecture audio sur l'hôte. En mode accessoire, Android achemine automatiquement sa sortie audio vers USB. Autrement dit, l'appareil Android sert de source de données à l'hôte, par exemple une station d'accueil.

L'audio en mode accessoire présente les caractéristiques suivantes :

• L'appareil Android doit être contrôlé par un hôte compétent qui peut d'abord faire passer l'appareil Android du mode développement au mode accessoire, puis l'hôte doit transférer les données audio à partir du point de terminaison approprié. Ainsi, l'appareil Android n'apparaît pas « sans pilote » à l'hôte.
• La direction doit être saisie , exprimée par rapport à l'hôte
• Le format audio doit être PCM 16 bits
• La fréquence d'échantillonnage doit être de 44,1 kHz
• Le nombre de canaux doit être de 2 (stéréo)

L’audio en mode accessoire n’a pas été largement adopté et n’est actuellement pas recommandé pour les nouvelles conceptions.

Applications de l'audio numérique USB

Comme son nom l'indique, le signal audio numérique USB est représenté par un flux de données numériques plutôt que par le signal analogique utilisé par le connecteur commun du mini-casque TRS. Finalement, tout signal numérique doit être converti en analogique avant de pouvoir être entendu. Il y a des compromis à faire pour choisir où placer cette conversion.

L'histoire de deux DAC

Dans le diagramme d’exemple ci-dessous, nous comparons deux conceptions. Nous avons d’abord un appareil mobile avec un processeur d’application (AP), un DAC intégré, un amplificateur et un connecteur TRS analogique connecté au casque. Nous considérons également un appareil mobile avec USB connecté à un DAC USB externe et à un amplificateur, également avec des écouteurs.

Figure 3. Comparaison de deux DAC

Quel design est le meilleur ? La réponse dépend de vos besoins. Chacun a ses avantages et ses inconvénients.

Remarque : Il s'agit d'une comparaison artificielle, car un véritable appareil Android aurait probablement les deux options disponibles.

La première conception A est plus simple, moins coûteuse, utilise moins d’énergie et sera une conception plus fiable en supposant des composants par ailleurs tout aussi fiables. Cependant, il existe généralement des compromis en matière de qualité audio par rapport à d'autres exigences. Par exemple, s’il s’agit d’un appareil grand public, il peut être conçu pour répondre aux besoins du consommateur général et non à ceux de l’audiophile.

Dans la deuxième conception, le périphérique audio externe C peut être conçu pour une qualité audio supérieure et une puissance de sortie supérieure sans impact sur le coût de l'appareil Android B grand public de base. Oui, il s'agit d'une conception plus coûteuse, mais le coût n'est absorbé que par ceux qui le veulent.

Les appareils mobiles sont connus pour avoir des circuits imprimés à haute densité, ce qui peut entraîner davantage de possibilités de diaphonie dégradant les signaux analogiques adjacents. La communication numérique est moins sensible au bruit , donc déplacer le DAC de l'appareil Android A vers une carte de circuit imprimé externe C permet aux étages analogiques finaux d'être physiquement et électriquement isolés de la carte de circuit imprimé dense et bruyante, ce qui permet d'obtenir un son d'une plus haute fidélité.

D’un autre côté, la deuxième conception est plus complexe, et une complexité accrue entraîne davantage de risques d’échec. Il existe également une latence supplémentaire de la part des contrôleurs USB.

Applications en mode hôte

Les applications audio typiques en mode hôte USB incluent :

• écouter de la musique
• téléphonie
• messagerie instantanée et chat vocal
• enregistrement

Pour toutes ces applications, Android détecte un périphérique audio numérique USB compatible et achemine automatiquement la lecture et la capture audio de manière appropriée, en fonction des règles de politique audio. Le contenu stéréo est diffusé sur les deux premiers canaux du périphérique.

Il n'existe aucune API spécifique à l'audio numérique USB. Pour une utilisation avancée, le routage automatique peut interférer avec les applications compatibles USB. Pour de telles applications, désactivez le routage automatique via le contrôle correspondant dans la section Médias de Paramètres / Options du développeur .

Déboguer en mode hôte

En mode hôte USB, le débogage adb via USB n'est pas disponible. Voir la section Utilisation sans fil d' Android Debug Bridge pour une alternative.

Implémenter l'audio USB

Recommandations pour les fournisseurs de périphériques audio

Afin d'interagir avec les appareils Android, les fournisseurs de périphériques audio doivent :

• conception pour la conformité des classes audio ; actuellement Android cible la classe 1, mais il est sage de prévoir la classe 2
• éviter les bizarreries
• test d'interopérabilité avec les appareils Android de référence et populaires
• documenter clairement les fonctionnalités prises en charge, la conformité de la classe audio, les exigences d'alimentation, etc. afin que les consommateurs puissent prendre des décisions éclairées

Recommandations pour les OEM d'appareils Android et les fournisseurs de SoC

Afin de prendre en charge l'audio numérique USB, les fabricants d'appareils OEM et les fournisseurs de SoC doivent :

• concevoir du matériel pour prendre en charge le mode hôte USB
• activer la prise en charge générique de l'hôte USB au niveau du framework via l'indicateur de fonctionnalité android.hardware.usb.host.xml
• activer toutes les fonctionnalités du noyau nécessaires : mode hôte USB, audio USB, mode de transfert isochrone ; voir Configuration du noyau Android
• se tenir au courant des dernières versions et correctifs du noyau ; malgré le noble objectif de conformité de classe, il existe des périphériques audio existants avec des bizarreries , et les noyaux récents ont des solutions de contournement pour ces bizarreries
• activer la politique audio USB comme décrit ci-dessous
• ajoutez audio.usb.default à PRODUCT_PACKAGES dans device.mk
• test d'interopérabilité avec les périphériques audio USB courants

Activer la politique audio USB

Pour activer l'audio USB, ajoutez une entrée au fichier de configuration de la stratégie audio. Celui-ci se trouve généralement ici :

device/oem/codename/audio_policy.conf

Le composant de chemin d'accès « oem » doit être remplacé par le nom de l'OEM qui fabrique l'appareil Android, et « codename » doit être remplacé par le nom de code de l'appareil.

Un exemple d'entrée est affiché ici :

audio_hw_modules {
  ...
  usb {
    outputs {
      usb_accessory {
        sampling_rates 44100
        channel_masks AUDIO_CHANNEL_OUT_STEREO
        formats AUDIO_FORMAT_PCM_16_BIT
        devices AUDIO_DEVICE_OUT_USB_ACCESSORY
      }
      usb_device {
        sampling_rates dynamic
        channel_masks dynamic
        formats dynamic
        devices AUDIO_DEVICE_OUT_USB_DEVICE
      }
    }
    inputs {
      usb_device {
        sampling_rates dynamic
        channel_masks AUDIO_CHANNEL_IN_STEREO
        formats AUDIO_FORMAT_PCM_16_BIT
        devices AUDIO_DEVICE_IN_USB_DEVICE
      }
    }
  }
  ...
}

Code source

L'implémentation audio de la couche d'abstraction matérielle (HAL) pour l'audio USB se trouve ici :

hardware/libhardware/modules/usbaudio/

Le HAL audio USB s'appuie fortement sur tinyalsa , décrit dans Terminologie audio . Bien que l'audio USB repose sur des transferts isochrones, cela est supprimé par l'implémentation ALSA. Ainsi, le HAL audio USB et le tinyalsa n'ont pas besoin de se soucier de cette partie du protocole USB.

Tester le son USB

Pour plus d'informations sur les tests CTS pour l'audio USB, consultez Tests du vérificateur USB Audio CTS .