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.

Spectateurs

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

Les utilisateurs finaux d'appareils Nexus doivent 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 destiné aux utilisateurs finaux, certains consommateurs audiophiles peuvent trouver des parties intéressantes.

Présentation 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

USB est un bus avec un seul initiateur d'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 de 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 canal vers un point de terminaison , une source de données ou un puits 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 tube de flux est utilisé pour le transfert de données unidirectionnel.

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

Il existe trois principaux modes de transfert de données : interruption , bloc et isochrone . Le mode isochrone sera discuté plus loin 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 bornes 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. 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 sur le mode de transfert de données en bloc USB.

Mode hôte

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

Étant donné que 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 :

OTG

Figure 1. Adaptateur mobile (OTG)

Un appareil Android peut ne pas fournir suffisamment d'énergie pour faire fonctionner un périphérique particulier, en fonction de la puissance dont le périphérique a besoin et de la capacité de l'appareil Android à 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 concentrateur alimenté tel que celui-ci :

Moyeu alimenté

Figure 2. Concentrateur 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'une station d'accueil qui sert d'hôte. La différence entre le mode développement et le mode accessoire est que les fonctions USB supplémentaires sont visibles pour l'hôte, au-delà de 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

Cours 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 et aux fonctions périphériques conformes aux classes d'interagir, sans connaissance détaillée du fonctionnement de l'autre. La conformité aux classes 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 adhèrent 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 d'appareils, 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 médias, tandis que le protocole de transfert de médias (MTP) est pour l'accès complet aux fichiers des 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.

Terminaux audio

Les bornes d'un périphérique audio sont typiquement 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 (CAN) 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 à une borne de sortie analogique. Le DAC est un puits pour l'hôte.

Chaînes

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 dits multicanaux . Il est courant d'interpréter un flux stéréo comme étant composé 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 dernier canal 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 des erreurs. 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 de paquet ni de retransmission en cas d'erreur.

Des transmissions isochrones se produisent à chaque période de début de trame (SOF). La période SOF est d'une milliseconde pour la pleine vitesse et de 125 microsecondes pour la haute vitesse. Chaque trame à pleine vitesse transporte jusqu'à 1023 octets de charge utile, et une trame à grande vitesse transporte jusqu'à 1024 octets. En les rassemblant, nous calculons le taux de transfert maximal à 1 023 000 ou 8 192 000 octets par seconde. Cela 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.

Dans le mode isochrone, il existe trois sous-modes :

  • Adaptatif
  • Asynchrone
  • Synchrone

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

Dans le sous-mode asynchrone (également appelé rétroaction implicite), le puits ou la source détermine la fréquence d'échantillonnage et l'hôte s'adapte. Le principal avantage théorique du sous-mode asynchrone est que l'horloge USB source ou collectrice est physiquement et électriquement plus proche (et peut même être identique 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 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 :

Sous-mode Nombre d'octets
par paquet
Taux d'échantillonnage
déterminé par
Utilisé pour le son
adaptatif variable héberger 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 (API niveau 21) et supérieur prend en charge un sous-ensemble de fonctionnalités de classe audio USB 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, 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 (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. C'est-à-dire que l'appareil Android sert de source de données à l'hôte, par exemple une station d'accueil.

L'audio en mode accessoire a ces caractéristiques :

  • L'appareil Android doit être contrôlé par un hôte compétent qui peut d'abord faire passer l'appareil Android du mode de 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 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 mini casque TRS commun. 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 l'exemple de diagramme ci-dessous, nous comparons deux conceptions. Nous avons d'abord un appareil mobile avec processeur d'application (AP), DAC intégré, amplificateur et connecteur TRS analogique attaché aux écouteurs. Nous considérons également un appareil mobile avec USB connecté à un DAC USB externe et à un amplificateur, également avec un casque.

Comparaison CNA

Figure 3. Comparaison de deux DAC

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 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 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 grand public et non à ceux de l'audiophile.

Dans la deuxième conception, le périphérique audio externe C peut être conçu pour une meilleure qualité audio 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 chère, 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égradent 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 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 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 de possibilités d'échec. Il existe également une latence supplémentaire 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'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 le contrôle correspondant dans la section Média des Paramètres / Options pour les développeurs .

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é à la classe audio ; actuellement Android cible la classe 1, mais il est judicieux 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é à 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 d'appareils et les fournisseurs de SoC doivent :

  • concevoir du matériel pour prendre en charge le mode hôte USB
  • activer la prise en charge de l'hôte USB générique au niveau de la structure 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
  • restez à jour avec les 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
  • ajouter audio.usb.default à PRODUCT_PACKAGES dans device.mk
  • tester l'interopérabilité avec les périphériques audio USB courants

Comment 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/

La 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, la HAL audio USB et la 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, consultez Tests du vérificateur CTS audio USB .