Cet article examine la compatibilité d'Android avec l'audio numérique USB et les protocoles USB associés.
Audience
L'audience cible de cet article est constituée 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 souhaitent comprendre en détail le fonctionnement interne 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 peuvent trouver des parties intéressantes.
Présentation de l'USB
L'Universal Serial Bus (USB) est décrit de manière informelle dans l'article de Wikipedia USB et est défini officiellement par les normes publiées par l'USB Implementers Forum, Inc. Pour des raisons de commodité, nous résumons ici les principaux concepts USB, mais les normes constituent la référence officielle.
Concepts et terminologie de base
L'USB est un bus avec un seul initiateur des 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 appareil et accessoire sont des synonymes courants de périphérique. Nous évitons ces termes ici, car ils pourraient être confondus avec l'appareil Android ou le concept spécifique à Android appelé mode accessoire.
L'énumération est un rôle d'hôte essentiel : il s'agit du 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 plusieurs fonctions logiques. Par exemple, un périphérique de webcam peut avoir à la fois une fonction de caméra et une fonction audio de micro.
Chaque fonction périphérique dispose d'une interface qui définit le protocole de communication avec cette fonction.
L'hôte communique avec un périphérique via un canal à un point de terminaison, une source ou un puits de données fourni par l'une des fonctions du périphérique.
Il existe deux types de canaux: message et flux. 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 lance 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, groupé et isochrone. Nous reviendrons sur le mode isochrone 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 le protocole USB en signaux "réels". 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 Android fastboot ou Android Debug Bridge (adb). Les protocoles fastboot et adb sont superposés au mode de transfert de données groupées 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 l'opération de l'hôte, un adaptateur OTG (On-The-Go) tel que celui-ci est généralement requis:
Figure 1 : Adaptateur 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 puissance adéquate est disponible, la durée de recharge de la batterie de l'appareil Android peut être considérablement réduite. Dans ces situations, utilisez un hub alimenté, comme celui-ci:
Figure 2. Hub alimenté
Mode accessoire
Le mode accessoire a été introduit dans Android 3.1 (niveau d'API 12) et rétroporté vers 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 réside dans le fait que l'hôte peut voir des fonctions USB supplémentaires, en plus d'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 est associée à un document de classe d'appareil qui spécifie le protocole standard de cette fonction. Cela permet aux hôtes et aux fonctions périphériques conformes à la classe d'interagir, sans connaissance détaillée de leur fonctionnement respectif. La conformité de classe est essentielle si l'hôte et le périphérique sont fournis par différentes entités.
Le terme sans pilote est un synonyme courant de conforme à la classe, ce qui signifie qu'il est possible d'utiliser les fonctionnalités standards d'un tel périphérique sans avoir à installer de 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 pour ordinateur de bureau sera conforme à la classe, bien que des exceptions puissent exister.
Classe audio USB
Ici, nous ne nous occupons que des périphériques qui implémentent des fonctions audio et qui respectent donc la classe d'appareils audio. Il existe deux éditions de la spécification de la classe audio USB: la classe 1 (UAC1) et la classe 2 (UAC2).
Comparaison avec d'autres classes
L'USB inclut 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 aux supports multimédias par secteur, tandis que le protocole de transfert multimédia (MTP) permet un accès complet aux fichiers multimédias. MSC et MTP peuvent être utilisés pour transférer des fichiers audio, mais seule la classe audio USB est adaptée au streaming en temps réel.
Terminaux audio
Les bornes d'un périphérique audio sont généralement analogiques. Le signal analogique présenté au terminal d'entrée du périphérique est converti en numérique par un convertisseur analogique-numérique (ADC) et est transmis 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) le convertit et le présente à un terminal de sortie analogique. Le DAC est un piège pour l'hôte.
Chaînes
Un périphérique avec fonction audio peut inclure un terminal source, un terminal de destination ou les deux. Chaque sens peut comporter 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 composé de canaux gauche et droit, et par extension d'interpréter un flux multicanal comme ayant des emplacements spatiaux correspondant à chaque canal. Toutefois, 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, il appartient à l'application et à l'utilisateur de définir l'utilisation de chaque canal. Par exemple, un flux d'entrée USB à quatre canaux peut avoir les trois premiers canaux connectés à différents micros 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 d'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). Toutefois, en cas d'erreur, il n'y a pas d'accusé de réception ni de nouvelle transmission des paquets.
Les 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 à grande vitesse. Chaque trame à pleine vitesse transporte jusqu'à 1 023 octets de charge utile, et une trame à haut débit transporte jusqu'à 1 024 octets. En réunissant ces informations, nous calculons le débit de transfert maximal à 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.
Le mode isochrone comporte trois sous-modes:
- Adaptatif
- Asynchrone
- Synchrone
En sous-mode adaptatif, le récepteur ou la source périphérique s'adapte à un taux d'échantillonnage potentiellement variable de l'hôte.
Dans le sous-mode asynchrone (également appelé "commentaires implicites"), le collecteur ou la source détermine le taux d'échantillonnage, et l'hôte s'y adapte. L'avantage théorique principal du sous-mode asynchrone est que l'horloge USB de la source ou du puits 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 au jitter de l'horloge. De plus, l'horloge utilisée par le DAC ou l'ADC peut être conçue pour une précision et une dérive plus élevées que l'horloge hôte.
En mode sous-synchrone, un nombre fixe d'octets est transféré à chaque période SOF. Le taux d'échantillonnage audio est effectivement dérivé 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écapitule les sous-modes isochrones:
| Sous-mode | Nombre d'octets par paquet |
Taux d'échantillonnage déterminé par |
Utilisé pour l'audio |
|---|---|---|---|
| intelligente | variable | hôte | oui |
| asynchrone | variable | périphérique | oui |
| synchrone | fixe | Horloge USB | non |
En pratique, le sous-mode a bien sûr son importance, mais d'autres facteurs doivent également être pris en compte.
Compatibilité d'Android avec la classe audio USB
Mode de développement
L'audio USB n'est pas compatible avec le mode développement.
Mode hôte
Android 5.0 (niveau d'API 21) ou version ultérieure est compatible avec un sous-ensemble de fonctionnalités de la classe audio USB 1 (UAC1) :
- L'appareil Android doit servir d'hôte
- Le format audio doit être PCM (type d'interface I)
- La profondeur de bits doit être de 16, 24 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.
- Le taux 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 égal à 1 (mono) ou à 2 (stéréo).
L'examen du code source du framework Android peut afficher du code supplémentaire au-delà du minimum requis pour prendre en charge ces fonctionnalités. Toutefois, ce code n'a pas été validé. Par conséquent, les fonctionnalités plus avancées ne sont pas encore revendiquées.
Mode accessoire
Android 4.1 (niveau d'API 16) a ajouté une compatibilité limitée avec la lecture audio à 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 fonctionnalités suivantes:
- L'appareil Android doit être contrôlé par un hôte compétent qui peut d'abord passer de son mode de développement au mode accessoire, puis transférer les données audio à partir du point de terminaison approprié. Par conséquent, l'appareil Android ne s'affiche pas comme "sans pilote" pour l'hôte.
- La direction doit être input (entrée), exprimée par rapport à l'hôte.
- Le format audio doit être PCM 16 bits
- Le taux d'échantillonnage doit être de 44,1 kHz.
- Le nombre de canaux doit être de deux (stéréo).
L'audio en mode accessoire n'a pas été largement adopté et n'est 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érique plutôt que par le signal analogique utilisé par le mini connecteur de casque TRS standard. Tout signal numérique doit être converti en signal analogique avant de pouvoir être entendu. Le choix de l'emplacement de cette conversion présente des avantages et des inconvénients.
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 (PA), un DAC intégré, un amplificateur et un connecteur TRS analogique connecté à un casque. Nous prenons également en compte un appareil mobile avec USB connecté à un DAC et un amplificateur USB externes, ainsi qu'à des écouteurs.
Figure 3. Comparaison de deux DAC
Quelle conception est la meilleure ? La réponse dépend de vos besoins. Chacune présente des avantages et des inconvénients.
Remarque:Il s'agit d'une comparaison artificielle, car un véritable appareil Android dispose probablement des deux options.
La première conception A est plus simple, moins coûteuse, consomme moins d'énergie et sera plus fiable, à condition que les composants soient également fiables. Toutefois, il existe généralement des compromis sur la qualité audio par rapport aux 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 moyen, et non pour les audiophiles.
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 plus élevée sans affecter le coût de l'appareil Android de base B. Oui, il s'agit d'une conception plus coûteuse, mais le coût n'est absorbé que par ceux qui le souhaitent.
Les appareils mobiles sont réputés pour avoir des cartes de circuits haute densité, ce qui peut entraîner davantage de diaphonie qui dégrade les signaux analogiques adjacents. La communication numérique est moins sensible au bruit. Par conséquent, le transfert du DAC de l'appareil Android A vers une carte de circuit imprimé externe C permet d'isoler physiquement et électriquement les étapes analogiques finales de la carte de circuit imprimé dense et bruyante, ce qui améliore la qualité audio.
D'un autre côté, la deuxième conception est plus complexe, et avec cette complexité supplémentaire, les risques de défaillance sont plus élevés. Les contrôleurs USB ajoutent également une latence supplémentaire.
Applications en mode hôte
Voici des exemples d'applications audio en mode hôte USB:
- É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 et la capture audio de manière appropriée, en fonction des règles de stratégie 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 prenant en charge l'USB. Pour ces applications, désactivez le routage automatique via le contrôle correspondant dans la section "Multimédia" de Paramètres / Options pour les développeurs.
Déboguer en mode hôte
En mode hôte USB, le débogage adb via USB n'est pas disponible. Pour découvrir une autre méthode, consultez la section Utilisation sans fil de Android Debug Bridge.
Implémenter l'audio USB
Recommandations pour les fournisseurs de périphériques audio
Pour assurer l'interopérabilité avec les appareils Android, les fournisseurs de périphériques audio doivent:
- Concevoir pour la conformité de la classe audio ; actuellement, Android cible la classe 1, mais il est judicieux de planifier la classe 2
- éviter les particularités
- tester l'interopérabilité avec des appareils Android courants et de référence ;
- documentez clairement les fonctionnalités prises en charge, la conformité avec la classe audio, les exigences d'alimentation, etc. afin que les consommateurs puissent prendre des décisions éclairées ;
Recommandations pour les OEM et les fournisseurs de SoC d'appareils Android
Pour prendre en charge l'audio numérique USB, les OEM d'appareils et les fournisseurs de SoC doivent:
- concevoir du matériel compatible avec le mode hôte USB ;
- Activer la compatibilité avec les hôtes USB génériques au niveau du framework via le flag de fonctionnalité
android.hardware.usb.host.xml - Activez toutes les fonctionnalités du noyau requises: mode hôte USB, audio USB, mode de transfert isochrone.
- Tenez-vous informé des dernières versions et correctifs du kernel. Malgré l'objectif noble de conformité de la classe, il existe des périphériques audio existants présentant des particularités, et les kernels récents proposent des solutions de contournement pour ces particularités.
- Activez la règle audio USB comme décrit ci-dessous.
- Ajout de audio.usb.default à PRODUCT_PACKAGES dans device.mk
- tester l'interopérabilité avec les périphériques audio USB courants ;
Activer la stratégie audio USB
Pour activer l'audio USB, ajoutez une entrée au fichier de configuration de la stratégie audio. Il se trouve généralement à cet emplacement:
device/oem/codename/audio_policy.conf
Le composant de chemin d'accès "oem" doit être remplacé par le nom du fabricant d'équipement d'origine qui fabrique l'appareil Android, et "codename" doit être remplacé par le nom de code de l'appareil.
Voici un exemple d'entrée:
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 de la couche d'abstraction matérielle (HAL) audio pour l'audio USB se trouve ici:
hardware/libhardware/modules/usbaudio/
Le HAL audio USB repose fortement sur tinyalsa, décrit dans la section Terminologie audio. Bien que l'audio USB repose sur des transferts isochrones, cela est abstrait par l'implémentation d'ALSA. Par conséquent, le HAL audio USB et tinyalsa n'ont pas besoin de se soucier de cette partie du protocole USB.
Tester l'audio USB
Pour en savoir plus sur les tests CTS pour l'audio USB, consultez Tests de vérification CTS pour l'audio USB.