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 qui recherchent une compréhension détaillée des internes audio numériques USB sur Android.

Les utilisateurs finaux d'appareils Nexus devraient plutôt consulter l'article Enregistrer et lire de l'audio à l'aide du mode hôte USB dans le centre d'aide Nexus . Bien que cet article ne soit pas orienté vers les utilisateurs finaux, certains consommateurs audiophiles peuvent trouver des parties d'intérêt.

Vue d'ensemble de l'USB

Universal Serial Bus (USB) est décrit de manière informelle dans l'article de Wikipedia USB , et est formellement défini par les normes publiées par l' USB Implementers Forum, Inc. Pour plus de commodité, nous résumons ici les principaux concepts USB, mais les normes sont la référence faisant autorité.

Concepts de base et terminologie

L'USB est un bus avec un seul initiateur des opérations de transfert de données, appelé l' 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 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 fait plusieurs fonctions logiques. Par exemple, un périphérique de webcam pourrait avoir à la fois une fonction caméra et une fonction audio de microphone.

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

L'hôte communique avec un périphérique via un tuyau vers un point d' extrémité , une source de données ou un puits fourni par l'une des fonctions du périphérique.

Il existe deux types de canaux: le message et le flux . Un canal de message est utilisé pour le contrôle bidirectionnel et l'état. Un tuyau d'écoulement est utilisé pour le transfert de données unidirectionnel.

L'hôte lance tous les transferts de données, par conséquent 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 à l'hôte, tandis qu'une opération de sortie transfère les données de l'hôte au périphérique.

Il existe trois principaux modes de transfert de données: interruption , bloc 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 manière, 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 sortie initiale d'Android. Le périphérique 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 Android Fastboot ou 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 (niveau d'API 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 mobile ( OTG ) tel que celui-ci est généralement requis:

OTG

Figure 1. Adaptateur mobile (OTG)

Un appareil Android peut ne pas fournir une puissance suffisante 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é d'énergie 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 raccourcie. Dans ces situations, utilisez un concentrateur alimenté tel que celui-ci:

Hub alimenté

Figure 2. Concentrateur alimenté

Mode accessoire

Le mode accessoire a été introduit dans Android 3.1 (niveau d'API 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'une station d'accueil qui sert d'hôte. La différence entre le mode de développement et le mode accessoire est 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, en particulier l'audio décrit ci-dessous.

Audio USB

Classes USB

Chaque fonction périphérique a un document de classe de périphérique associé 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 des uns et des autres. 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 nécessaire» pour les principaux systèmes d'exploitation de bureau sera conforme à la classe, bien qu'il puisse y avoir des exceptions.

Classe audio USB

Ici, nous nous intéressons uniquement aux périphériques qui implémentent des fonctions audio, et donc adhèrent à 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 l'accès sectoriel aux supports, tandis que le protocole de transfert de supports (MTP) est pour l'accès complet aux fichiers aux supports. MSC et MTP peuvent tous deux être utilisés pour transférer des fichiers audio, mais seule la classe audio USB convient à la diffusion 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) se convertit et se présente à une borne de sortie analogique. Le DAC est un puits pour l'hôte.

Canaux

Un périphérique avec 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 avec 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 HDMI ) de ne pas attribuer de signification spatiale standard particulière à chaque canal. Dans ce cas, il appartient à 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 à divers 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 d'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'acquittement ou de retransmission de paquet en cas d'erreur.

Les transmissions isochrones se produisent à chaque période de début de trame (SOF). La période SOF est d'une milliseconde pour la vitesse maximale et de 125 microsecondes pour la vitesse élevée. Chaque trame pleine vitesse transporte jusqu'à 1023 octets de charge utile, et une trame haute vitesse porte jusqu'à 1024 octets. En les rassemblant, nous calculons le taux de transfert maximal comme étant de 1 023 000 ou 8 192 000 octets par seconde. Ceci définit une limite supérieure théorique sur 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 l'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 en fait être la même que, ou dérivée de) l'horloge qui pilote le DAC ou ADC. Cette proximité signifie que le sous-mode asynchrone devrait être moins sensible à la gigue d'horloge. En outre, l'horloge utilisée par le DAC ou ADC peut être conçue pour une précision plus élevée et une dérive inférieure à celle de 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:

Sous-mode Nombre d'octets
par paquet
Taux d'échantillonnage
déterminé par
Utilisé pour l'audio
adaptatif variable hôte Oui
asynchrone variable périphérique Oui
synchrone fixé Horloge USB non

En pratique, le sous-mode importe bien sûr, mais d'autres facteurs doivent également être pris en compte.

Prise en charge d'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 (niveau d'API 21) et supérieur prend en charge un sous-ensemble de fonctionnalités USB audio de classe 1 (UAC1):

  • L'appareil Android doit agir en tant qu'hôte
  • Le format audio doit être PCM (type d'interface I)
  • La profondeur de bits doit être de 16 bits, 24 bits ou 32 bits où 24 bits de données audio utiles sont 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 afficher 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 (niveau d'API 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 un dock.

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 entrée , 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 de mini- casque TRS commun. Finalement, tout signal numérique doit être converti en analogique avant de pouvoir être entendu. Il y a des compromis dans le choix de l'emplacement de cette conversion.

L'histoire de deux DAC

Dans l'exemple de diagramme ci-dessous, nous comparons deux conceptions. Tout d'abord, nous avons un appareil mobile avec un processeur d'application (AP), un DAC intégré, un amplificateur et un connecteur TRS analogique attachés aux écouteurs. Nous considérons également un appareil mobile avec USB connecté à un DAC USB externe et à un amplificateur, également avec des écouteurs.

Comparaison DAC

Figure 3. Comparaison de deux CNA

Quelle conception est la meilleure? 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 vrai 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 également fiables. Cependant, il existe généralement des compromis entre la qualité audio et d'autres exigences. Par exemple, s'il s'agit d'un appareil destiné au marché de masse, il peut être conçu pour répondre aux besoins du consommateur en général, et non pour 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 plus grande puissance de sortie sans impact sur le coût de l'appareil Android de base du marché de masse B. Oui, c'est 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 cartes de circuits imprimés haute densité, ce qui peut entraîner davantage de possibilités de diaphonie qui dégrade les signaux analogiques adjacents. La communication numérique est moins sensible au bruit , donc le déplacement du DAC de l'appareil Android A vers une carte de circuit externe C permet aux étapes analogiques finales d'être physiquement et électriquement isolées de la carte de circuit imprimé dense et bruyante, ce qui se traduit par un son plus fidèle.

D'un autre côté, la deuxième conception est plus complexe et, avec une complexité accrue, il y a plus d'opportunités pour que les choses échouent. Il existe également une latence supplémentaire des contrôleurs USB.

Applications en mode hôte

Les applications audio typiques du mode hôte USB comprennent:

  • écoute de 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 audio et la capture de manière appropriée, en fonction des règles de politique audio. Le contenu stéréo est lu sur les deux premiers canaux du périphérique.

Il n'y a pas d'API spécifiques à 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 la commande correspondante dans la section Médias des Paramètres / Options du développeur .

Débogage 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émentation de 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é de la classe audio; actuellement Android cible la classe 1, mais il est sage de prévoir la classe 2
  • éviter les bizarreries
  • tester l'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 équipementiers 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 des hôtes USB génériques 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 de telles bizarreries
  • activer la politique audio USB comme décrit ci-dessous
  • ajouter audio.usb.default à PRODUCT_PACKAGES dans device.mk
  • test d'interopérabilité avec les périphériques audio USB courants

Comment activer la stratégie audio USB

Pour activer l'audio USB, ajoutez une entrée au fichier de configuration de la politique audio. Ceci est généralement situé ici:

device/oem/codename/audio_policy.conf

Le composant de chemin "oem" doit être remplacé par le nom de l'OEM qui fabrique l'appareil Android, et "nom de code" doit être remplacé par le nom de code de l'appareil.

Un exemple d'entrée est présenté 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 Hardware Abstraction Layer (HAL) pour l'audio USB se trouve ici:

hardware/libhardware/modules/usbaudio/

Le HAL audio USB repose fortement sur tinyalsa , décrit dans Audio Terminology . Bien que l'audio USB repose sur des transferts isochrones, cela est éliminé par l'implémentation ALSA. Ainsi, l'audio USB HAL et tinyalsa n'ont pas besoin de se préoccuper de cette partie du protocole USB.

Test de l'audio USB

Pour plus d'informations sur les tests CTS pour l'audio USB, voir Tests USB Audio CTS Verifier .