Notes techniques

reTONE adapte l’étendue de son intervention au format du morceau, à la version d’Android et à la sortie. Pour les morceaux PCM, la conversion de fréquence d’échantillonnage a lieu au plus une fois sur les chemins gérés par reTONE (en interne, une conversion peut utiliser plusieurs étages de filtre) (pour le DSD, au plus une fois après l’étape de conversion DSD vers PCM). Avec le Bluetooth, le téléphone et le codec Bluetooth traitent ensuite encore le son. La lecture repose sur MediaPlayer et AudioTrack d’Android, et le moteur de reTONE (écrit en C) se charge du décodage et de la conversion en amont.

Android 4.x : de nombreux téléphones Android 4.x ouvrent le fil de sortie musicale à une fréquence fixe, par exemple 48 kHz, et les morceaux à une autre fréquence, comme 44.1 kHz ou 96 kHz, sont rééchantillonnés dans le mixeur d’Android avant la lecture. Les applications n’ont aucun moyen d’empêcher cette conversion. Le décodeur standard de la 4.x peut aussi ramener le FLAC 24 bits à 16 bits, ou ne pas ouvrir un FLAC 192 kHz. C’est pourquoi, sous 4.x, le moteur de reTONE lit tous les FLAC et WAV, ainsi que les DSF, DFF et AIFF, les convertit une seule fois à la fréquence de sortie du téléphone (la valeur d’AudioTrack.getNativeOutputSampleRate) et les transmet en 16 bits. Le mixeur d’Android accepte tel quel l’audio 16 bits à la même fréquence ; aucune conversion de fréquence d’échantillonnage n’a donc lieu côté Android. Lors de la réduction à 16 bits, les valeurs que 16 bits peuvent représenter exactement (comme l’audio CD transmis sans conversion) sont transmises inchangées ; sinon, reTONE applique un dither TPDF et, lorsque la sortie est à 44.1 kHz ou 48 kHz, un façonnage du bruit par rétroaction d’erreur (filtre à 5 coefficients pondéré E de Lipshitz, Vanderkooy et Wannamaker) pour déplacer le bruit de quantification vers des fréquences moins audibles. En cas d’écrêtage, l’erreur réinjectée est limitée à ±4 LSB pour éviter les oscillations. Les coefficients ont été conçus pour 44.1 kHz et sont aussi utilisés à 48 kHz. La quantité totale de bruit augmente, mais elle est déplacée vers les hautes fréquences, où l’oreille est moins sensible. Cependant, si vous réglez le volume d’Android en dessous du maximum, le mixeur d’Android arrondit de nouveau à 16 bits après avoir appliqué le volume, ce qui réduit l’intérêt du façonnage du bruit. Cela ne concerne pas les téléphones qui règlent le volume au niveau matériel. Dans tous les cas, aucune conversion de fréquence d’échantillonnage n’a lieu. Les formats MP3, AAC et similaires sont lus par le chemin standard d’Android, y compris sous 4.x.

Android 5 et versions ultérieures (chemins passant par le mixeur) : sous Android 10 et versions ultérieures, les chemins qui n’utilisent pas la sortie directe relèvent aussi de ce cas. Le mixeur d’Android de cette génération accepte le flottant ; le moteur de reTONE transmet donc à AudioTrack un son en flottant, sans dither. Sur les téléphones à sortie 16 bits, Android l’arrondit ensuite à 16 bits (Android n’applique pas de dither à ce stade). Les morceaux FLAC, WAV et ALAC dont la fréquence d’échantillonnage diffère de celle de la sortie du téléphone seraient rééchantillonnés par le mixeur d’Android s’ils lui étaient transmis tels quels, et les morceaux de plus de 16 bits seraient tronqués à 16 bits. Le rééchantillonneur par défaut d’AOSP utilise une qualité dynamique moyenne (DYN_MED) lorsque le réglage de qualité (af.resampler.quality) n’est pas défini, et passe à une qualité encore plus basse lorsque la charge estimée des rééchantillonneurs utilisés simultanément dépasse une limite. Sur le téléphone que nous avons vérifié, ce réglage n’était pas défini. Le moteur de reTONE ne rééchantillonne que les morceaux qui remplissent ces conditions, et vous pouvez le désactiver avec le réglage « Conversion by reTONE ». Les morceaux 16 bits à la fréquence de sortie du téléphone (comme l’audio CD sur un téléphone à 44.1 kHz) n’ont besoin d’aucune conversion et sont donc lus par le chemin standard d’Android.

Sortie directe (Android 10 et versions ultérieures ; disponibilité selon le téléphone) : la disponibilité de la « sortie directe », qui envoie le son à la fréquence du morceau sans passer par le mixeur, et de l’« offload », qui décode l’audio compressé sur la puce, dépend du téléphone et de la sortie. Sous Android 10 et versions ultérieures, une application peut demander au téléphone, avec AudioTrack.isDirectPlaybackSupported, si un format, une fréquence et une profondeur de bits donnés peuvent être envoyés directement vers la sortie actuelle. reTONE n’emprunte ce chemin que lorsque le téléphone répond oui et que la politique audio du téléphone achemine effectivement le PCM vers la sortie directe ; sinon, il lit par le chemin standard d’Android. La réponse varie selon la sortie ; reTONE pose donc la question à nouveau chaque fois qu’un casque ou un appareil USB est branché ou débranché. Sur les téléphones dont la politique audio achemine le PCM vers la sortie directe, les principaux formats qui ne pouvaient pas être envoyés directement étaient le PCM 16 bits à 44.1, 48 et 88.2 kHz (l’audio CD appartient à ce groupe). Le 24 bits et le flottant pouvaient être envoyés directement à la fréquence du morceau, et les MP3 et AAC (morceaux de 60 secondes ou plus) passaient en offload. reTONE décode donc l’audio sans perte 16 bits (FLAC, ALAC, WAV) en PCM (l’ALAC avec le décodeur propre à reTONE si le téléphone n’en a pas) et le transmet à MediaPlayer via MediaDataSource sous forme de WAV 24 bits dont les 8 bits de poids faible sont remplis de zéros. Les 16 bits de poids fort restent inchangés. Avant de basculer, il décode réellement le premier bloc pour confirmer qu’un véritable PCM 16 bits en sort, et revient au chemin standard s’il ne peut pas le confirmer. L’audio sans perte 24 bits ou à haute fréquence, ainsi que les MP3 et AAC, passent déjà par la sortie directe ou l’offload ; ils sont donc transmis tels quels. Les applications n’ont aucun moyen de lire quelle sortie le téléphone a réellement utilisée ; « DIRECT » sur l’écran du lecteur est donc une attente. reTONE se fiait auparavant à la seule réponse du téléphone, mais Android d’origine peut encore envoyer le PCM au mixeur même lorsqu’il répond oui, et certains téléphones affichaient DIRECT alors que l’audio n’était pas réellement direct. Depuis la 0.92.48, reTONE vérifie aussi la politique audio du téléphone. Depuis la 0.90.1, « DIRECT » n’est affiché que pour les morceaux sans perte, et jamais en Bluetooth. Avec l’offload, nous ne pouvons pas non plus vérifier si la fréquence d’échantillonnage change à l’intérieur de la puce. Sur ce chemin, les effets sonores côté Android ne sont pas appliqués (sur certains téléphones, les effets s’exécutent dans la puce), tandis que les réglages matériels du DAC (comme les filtres) restent actifs. Il peut être activé ou désactivé dans les réglages.

Sortie directe vers les DAC USB : lorsque vous branchez un DAC USB sur un téléphone prenant en charge l’hôte USB (OTG), reTONE envoie les données directement au DAC sans passer par le chemin audio d’Android. Sur le téléphone que nous avons vérifié, le chemin standard d’Android convertissait le son en 16 bits/48 kHz pour le DAC USB (une sortie en 32 bits/192 kHz était aussi ouverte, mais n’était pas utilisée pour la musique). La sortie directe de reTONE fonctionne comme suit.

• Grâce à l’API hôte USB du téléphone, reTONE trouve le DAC, obtient votre autorisation et lit les descripteurs USB (pour l’USB Audio Class 2.0 : l’ID d’horloge, les réglages alternatifs de l’interface de lecture, le point de terminaison de sortie et le point de terminaison de retour ; pour la Class 1.0 : les fréquences d’échantillonnage et la taille de paquet de chaque réglage alternatif).
• Il prend le contrôle du DAC à la place du pilote d’Android (claimInterface) et privilégie un réglage alternatif PCM, 2 canaux, 32 bits (24 ou 16 bits à défaut).
• Il lit les fréquences d’échantillonnage prises en charge avec GET RANGE de la source d’horloge. Si la fréquence du morceau est dans la plage, il la définit avec SET CUR et la confirme avec GET CUR. Seuls les morceaux à des fréquences non prises en charge, ou à des fréquences que l’USB du téléphone refuse d’acheminer (depuis la 0.92.68), sont rééchantillonnés, une seule fois, par reTONE vers une fréquence acceptée par le DAC. Les morceaux aux fréquences prises en charge par le DAC ne subissent ni conversion de fréquence d’échantillonnage ni dither. Les morceaux jusqu’à 24 bits sont envoyés avec les données d’origine placées telles quelles dans les bits de poids fort d’un mot de 32 bits (lorsque le volume du DAC est utilisé ou lorsque le volume est réglé sur le DAC lui-même). Les morceaux entiers 32 bits suivent aussi un chemin qui les conserve en entiers (depuis la 0.92.65). Seules les valeurs que la profondeur de bits du DAC ne peut pas représenter exactement sont arrondies, avec un dither TPDF lorsque le DAC est de 24 bits ou moins.
• Les transferts sont gérés côté C par des transferts isochrones usbdevfs. Pour les DAC High Speed qui reçoivent du son toutes les 0.125 ms (la plupart), 1 ms de son (8 microtrames) est regroupée en un transfert, et 64 de ces transferts sont tenus en file d’avance. Pour les DAC à intervalle plus long, chaque transfert contient 32 paquets et moins de transferts sont mis en file, pour conserver environ 64 ms d’avance. Les DAC asynchrones indiquent le nombre de trames par microtrame depuis le point de terminaison de retour, et reTONE ajuste en conséquence la quantité envoyée. Le format de cette valeur varie selon les DAC ; reTONE le détecte donc à partir de ce qui arrive. Lorsque reTONE applique le volume, il le fait juste avant l’envoi, de sorte que les changements prennent effet immédiatement (chaque changement est lissé sur environ 5 ms pour éviter les à-coups).
• Pendant ce temps, les MP3, AAC et formats similaires sont aussi décodés en PCM avec le décodeur du téléphone (MediaCodec) avant l’envoi : reTONE lit donc tous les morceaux. Débrancher le DAC met la lecture en pause. Lorsqu’une autre application commence à lire, reTONE se met en pause et rend le DAC à Android, puis le reprend lorsque vous relancez la lecture dans reTONE. Si le DAC n’est pas rendu à Android, par exemple après un arrêt forcé, reTONE le rend juste après une mise à jour, et lorsque vous ouvrez reTONE avec « USB DAC direct output » désactivé.

De nombreux téléphones de la génération Android 4.1 ne peuvent pas utiliser un DAC USB comme sortie audio, mais la sortie directe de reTONE n’utilise que la fonction hôte USB ; elle peut donc quand même envoyer le son. Avec notre téléphone d’essai de 2012 (Android 4.1) et un DAC sur batterie, du 24 bits/192 kHz a été lu sans conversion. Nous avons testé nous-mêmes des DAC USB Audio Class 2.0. Les DAC Class 1.0 sont aussi pris en charge, mais les essais en conditions réelles proviennent pour l’instant uniquement de retours d’utilisateurs. Les téléphones plus anciens ne peuvent fournir qu’un faible courant via USB ; les DAC alimentés par le bus peuvent donc ne pas être reconnus. Nous avons aussi constaté un cas où des interférences radio du Wi-Fi atteignaient le DAC par le câble USB et provoquaient des bruits intermittents. La lecture n’a pas besoin de connexion ; nous recommandons donc de passer en mode avion pour écouter avec un DAC USB.

La conversion de fréquence d’échantillonnage recalcule la forme d’onde entre les échantillons d’origine : la qualité du filtre se retrouve donc directement dans le son. Le filtre de reTONE est un filtre FIR obtenu en appliquant une fenêtre de Kaiser à une fonction sinc. Il utilise une structure polyphase, qui répartit les coefficients en groupes selon le rapport de conversion et ne calcule que le nécessaire. La conception repose sur deux critères : ne pas atténuer le son audible, et maintenir le repliement causé par la conversion bien maîtrisé.

• Bande passante : plate jusqu’à 20 kHz (à ±0.001 dB près par conception ; pour les conversions entre fréquences de 44.1 kHz ou plus).
• Bande coupée : commence à « la fréquence la plus basse − 20 kHz ». Entre 44.1 kHz et 48 kHz, cela donne 24.1 kHz. Le repliement qui tombe dans cette plage apparaît au-dessus de 20 kHz et reste hors de la bande audible (jusqu’à 20 kHz).
• Atténuation (objectif de conception) : 120 dB pour les téléphones à sortie en flottant (Android 5 et versions ultérieures), 100 dB pour les téléphones à sortie 16 bits (Android 4.x). La longueur du filtre et la fenêtre sont conçues avec une marge de 2 dB par rapport à l’objectif, de sorte que la valeur calculée dépasse l’objectif pour chaque conversion (pour 44.1 → 48 kHz, les valeurs calculées sont d’environ 122 dB et d’environ 102 dB). Un repliement résiduel à −100 dB se situe bien en dessous du plancher de bruit en 16 bits (environ −93 dBFS en pleine bande, dither compris) : une atténuation de 100 dB n’est donc pas différente à l’oreille de 120 dB.
• Nombre de coefficients : déterminé à partir de l’atténuation et de la bande de transition à l’aide de la formule de la fenêtre de Kaiser (86 coefficients pour 44.1 ↔ 48 kHz à 120 dB).
• Étages 2:1 : les étages qui divisent exactement la fréquence par deux, comme 96 → 48 kHz, utilisent un filtre demi-bande, dont la moitié des coefficients sont nuls et les autres symétriques, ce qui ramène le nombre de multiplications à environ un quart de celui d’un filtre ordinaire. 192 → 48 kHz utilise deux étages demi-bande, et les rapports restants, comme 88.2 → 48 kHz, sont traités par un filtre polyphase.

Lors des mesures, des signaux à 1 kHz, 19 kHz et 19.9 kHz sont ressortis au même niveau à 0.01 dB près. Avec une entrée à 30 kHz, le repliement apparaissant entre 0 et 20 kHz se situait au moins 104.6 dB sous le signal d’origine en sortie 44.1 kHz et 48 kHz, et au moins 116 dB en dessous pour une conversion depuis 192 kHz (mesuré avant l’arrondi à 16 bits). Ce sont des valeurs à une seule fréquence. Par conception, toute la bande atténuée est réduite au moins jusqu’aux objectifs d’atténuation ci-dessus.

Comme la conversion crée de nouveaux points entre les échantillons d’origine, les morceaux forts peuvent présenter des points au-dessus de 0 dBFS. Lorsque nous avons converti en 48 kHz plusieurs enregistrements du commerce que nous avions, les points au-dessus de 0 dBFS représentaient 0.0001 à 0.001 % du total, avec des maxima de +0.38 à +0.59 dB. Ils sont écrêtés à la sortie 16 bits ou dans le mixeur du téléphone ; lorsqu’il rééchantillonne, et seulement dans ce cas, reTONE abaisse donc le niveau de 1 dB, ce qui laisse une marge au-dessus du maximum mesuré. Les morceaux qui ne sont pas rééchantillonnés restent inchangés ; sur un même téléphone, les morceaux rééchantillonnés sont donc 1 dB plus faibles. Lors du passage sans coupure au morceau suivant, l’état du rééchantillonneur est reporté, de sorte que le début et la fin des morceaux ne sont pas rognés par le traitement (depuis la 0.92.57).

Le volume n’est pas appliqué dans le moteur de reTONE, mais dans le mixeur d’Android (le volume d’AudioTrack). L’appliquer dans le moteur retarderait les changements jusqu’à la fin de la lecture des quelque 500 ms d’audio en mémoire tampon dans AudioTrack, et les touches de volume paraîtraient lentes à réagir. Sur les téléphones à sortie 16 bits, baisser le volume conduit Android à arrondir de nouveau à 16 bits (Android n’applique pas de dither à cette étape).

Les calculs sont écrits en C et utilisent les instructions ARM NEON pour traiter ensemble les canaux gauche et droit. La boucle interne du filtre lit les coefficients sous forme de vecteurs et utilise quatre accumulateurs pour masquer la latence. Le dither, y compris les nombres aléatoires, l’arrondi, l’écrêtage et la rétroaction d’erreur, est lui aussi entièrement réalisé en NEON, ce qui évite les transferts entre NEON et les registres généraux, lents sur les cœurs plus anciens (Cortex-A9). Les builds Intel (x86) utilisent un chemin en C simple, sans NEON. Les chiffres de charge ci-dessous proviennent des téléphones ARM que nous avons testés.

Il y a trois endroits où baisser le volume : ① dans reTONE, appliqué aux données (numérique), ② le volume numérique interne du DAC, piloté via USB, et ③ le bouton ou les touches du DAC lui-même. Celui qui est utilisé dépend de la méthode de réglage choisie lors de la première connexion du DAC, et du fait que le DAC prenne ou non en charge le réglage du volume via USB.

② Volume via USB : l’USB Audio Class prévoit un mécanisme de volume appelé Feature Unit, dont GET RANGE lit le minimum, le maximum et le pas (en unités de 1/256 dB). reTONE convertit son volume (un gain unique combinant les paliers d’Android et le volume fin) en dB. S’il se situe dans cette plage, reTONE l’envoie au DAC et maintient sa propre sortie au maximum. Ce n’est que lorsque le volume descend sous cette plage que le complément est appliqué au PCM par ①. 0 correspond au silence.

① Dans reTONE : pour les DAC sans volume Feature Unit, et pour les DAC réglés sur « reTONE adjusts », reTONE applique le volume aux données avant de les envoyer, en lissant chaque changement sur environ 5 ms. Il est appliqué juste avant l’envoi ; les touches de volume réagissent donc immédiatement.

③ Le DAC lui-même : la présence d’un réglage de volume propre au DAC ne peut pas être lue via USB. C’est pourquoi, la première fois que vous connectez un DAC, reTONE vous demande une fois comment régler son volume, avec trois choix : « On the DAC itself », « Volume keys (DAC adjusts) » et « Volume keys (reTONE adjusts) ». Certains DAC indiquent qu’ils ont accepté une commande de volume sans modifier réellement le volume ; pour ceux-là, choisir « reTONE adjusts » fixe le volume du DAC au maximum et l’abaisse avec ①. Si vous choisissez « On the DAC », ② et ① sont tous deux fixés au maximum, et appuyer sur les touches de volume ne change rien (un message vous l’indique). Avec les DAC dotés d’un réglage de volume analogique, éviter l’atténuation numérique permet de tirer le meilleur parti du DAC. Le choix est mémorisé pour chaque modèle de DAC (ID de fournisseur et ID de produit USB) et peut être modifié avec le réglage « DAC volume ».

Lorsque « On the DAC » est choisi, ou lorsque le volume du DAC est utilisé (dans la plage de volume du DAC), les morceaux aux fréquences prises en charge par le DAC sont envoyés sans modification des données. Ce n’est que si vous réglez le volume sous la plage du DAC que reTONE applique le reste. Dans ce cas, si le morceau est sans perte (DSD natif compris) et que sa profondeur de bits tient dans celle du DAC, l’écran du chemin du signal affiche BIT-PERFECT (pour les morceaux entiers 32 bits, uniquement s’ils suivent le chemin en entiers). Ce qui se passe à l’intérieur du DAC ne peut pas être vérifié.

Les morceaux DSF et DFF sont envoyés en DSD, sans conversion en PCM, uniquement lorsque le DAC prend en charge le DSD natif et que son volume peut être réglé via USB (et que le DAC n’est pas réglé sur « reTONE adjusts »). reTONE ne peut pas modifier le volume du DSD lui-même ; un réglage du volume côté DAC est donc nécessaire. L’écran du lecteur affiche par exemple « DSD64 → USB AUDIO • DSD64 DIRECT ».

Il est envoyé comme suit.

• Le DSD natif fonctionne avec les DAC dont les descripteurs USB comportent un réglage alternatif pour les données brutes (TYPE I RAW DATA).
• Les bits DSD sont regroupés par 4 octets dans un mot de 32 bits par canal, le bit le plus ancien en tête. Le DSF stocke les bits en commençant par le poids faible ; l’ordre des bits de chaque octet est donc inversé avant le regroupement. Les mots sont envoyés en big-endian (même hypothèse que le DSD_U32_BE de Linux). Ce regroupement est réalisé en C, et le tampon circulaire de transfert contient environ 500 ms.
• L’horloge du DAC est réglée sur « fréquence DSD ÷ 32 » (88.2 kHz pour le DSD64, 176.4 kHz pour le DSD128).
• Les silences, les pauses et les fins de morceau sont remplis avec le motif de silence DSD 0x69.

Cet ordre des octets et cet ordre des bits ont été vérifiés par une lecture correcte sur le DAC que nous avons testé. Ils n’ont pas encore été vérifiés avec d’autres DAC, et le DoP (DSD over PCM) n’est pas pris en charge. Les fichiers DFF compressés en DST ne peuvent pas non plus être lus.

Envoi du DSD (réglage) : « Sending DSD » apparaît sous « Sound » dans les réglages uniquement lorsqu’un DAC capable d’utiliser le DSD natif est connecté. Le choix par défaut est « Send as DSD » (le DAC lit directement le DSD), et vous pouvez passer à « Convert to PCM » (reTONE le convertit en PCM). Si les morceaux DSD se coupent, ou si vous préférez la lecture en PCM, choisissez la conversion en PCM. Le choix est mémorisé pour chaque modèle de DAC, et le changement rouvre le morceau en cours à la même position. Nous avons trouvé un DAC qui se coupait brièvement sur des enregistrements DSD dont la modulation dépassait le niveau de référence de 50 %. Le transfert était normal : cela semble donc tenir à la conception du DAC. Dans ce cas aussi, la conversion en PCM évite les coupures.

Conversion DSD → PCM : lorsque le DSD natif n’est pas utilisé (avec les DAC qui ne remplissent pas les conditions, lorsque « Convert to PCM » est choisi, et pour la sortie vers le Bluetooth, les écouteurs ou le haut-parleur), reTONE convertit le DSD en PCM en deux étapes.

• Étape 1 : le flux binaire DSD est décimé d’un facteur 32, 64, etc., en PCM à environ 88.2 kHz ou plus (le DSD64 par 32 vers 88.2 kHz, le DSD128 par 64 vers 88.2 kHz). Le filtre est un filtre FIR à fenêtre de Kaiser. La bande passante s’étend jusqu’à la plus grande valeur entre 20 kHz et le quart de la fréquence de sortie, la bande atténuée commence à « fréquence de sortie − bande passante », et l’atténuation est de 100 dB pour une sortie 16 bits et de 110 dB pour le float et l’USB. Le nombre de coefficients est déterminé par la formule de la fenêtre de Kaiser. Le calcul utilise des tables de correspondance 16 bits, construites une fois par configuration puis réutilisées. Lors des mesures, la réponse à 20 kHz était de 0.000 dB, et le repliement sous 20 kHz de −101 dB (conception à 100 dB) / −110 à −117 dB (conception à 110 dB).
• Étape 2 : si nécessaire, le même rééchantillonneur que celui décrit dans la section sur le filtre effectue une seule conversion vers la fréquence de sortie du téléphone (par exemple 44.1 kHz ou 48 kHz pour la sortie intégrée).
• Niveau : converti de sorte que le 0 dB SACD (modulation de 50 %) corresponde à −6 dBFS (une convention courante ; depuis la version 0.69.0. Les versions antérieures utilisaient −12 dBFS et lisaient 6 dB moins fort).

Lors de l’envoi de PCM à un DAC USB, reTONE envoie tel quel du PCM à « fréquence DSD ÷ 32 » (88.2 kHz pour le DSD64, 176.4 kHz pour le DSD128, 352.8 kHz pour le DSD256), sans la conversion de l’étape 2, si le DAC le prend en charge. Le DSD étant converti en PCM, DIRECT n’est pas affiché dans ce cas.

reTONE vise à « ne rien faire à l’arrêt » et à « ne rien dessiner pendant la lecture écran éteint ». Les tâches périodiques ne s’exécutent que pendant la lecture : toutes les secondes écran allumé et toutes les 5 secondes écran éteint, et la barre de progression de l’écran de lecture ne redessine qu’elle-même toutes les 250 ms. L’horloge et la batterie sont mises à jour par des notifications du système, sans interrogation périodique.

Utilisation du CPU par reTONE, rapportée à un cœur, sur notre téléphone de test de 2012 (Android 4.1, Cortex-A9 à 2 cœurs).

• À l’arrêt : 0 %.
• Lecture écran éteint : le dessin s’arrête. Les morceaux lus par la lecture standard d’Android consomment presque 0 %, tandis que ceux lus par le moteur de reTONE (FLAC, WAV et autres sous Android 4.x) ajoutent la charge de décodage et de conversion indiquée ci-dessous.
• Lecture avec l’écran de lecture affiché : environ 2 % (mesuré pendant une lecture réelle ; essentiellement le rafraîchissement de la barre de progression, décodage non compris).
• Moteur de reTONE sortant un CD audio (16 bits/44.1 kHz) tel quel à 44.1 kHz : environ 2 %. Conversion vers 48 kHz pour la sortie : environ 4 %.
• Conversion de 24 bits/96 kHz vers 48 kHz : environ 5 %. Vers 44.1 kHz : environ 7 %.
• Conversion de 24 bits/192 kHz vers 44.1 kHz : environ 10 % (calcul seul) à environ 15 % (estimation approximative de la charge totale de lecture, ramenée à la fréquence d’horloge maximale).
• Envoi de 24 bits/192 kHz à un DAC USB sans conversion : environ 20 % (mesuré pendant une lecture réelle, écran allumé, thread de transfert compris).

Les valeurs du moteur, de « CD audio » à « 24 bits/192 kHz », proviennent de l’exécution des mêmes calculs à pleine vitesse, à fréquence d’horloge maximale, ramenés en pourcentage du temps réel. Pendant une lecture réelle, le téléphone abaisse sa fréquence d’horloge entre 200 MHz et 1 GHz : les valeurs affichées sur le téléphone paraissent donc 2 à 3 fois plus élevées (20 à 29 % pour le 24 bits/192 kHz). La manière d’écrire le code compte aussi beaucoup : l’implémentation actuelle en C et NEON représentait environ un tiers à un cinquième de la charge d’un premier prototype écrit en Java.

Pour la conversion DSD vers PCM, avec ce téléphone de 2012 et un DAC sur batterie, la conversion du DSD64 en PCM 88.2 kHz et son envoi via USB prenaient environ 11.8 % pour la conversion et environ 5.8 % pour le transfert USB (à environ 1 GHz). Lors de la lecture de DSD64 par la sortie intégrée (48 kHz) d’un téléphone Android 4.4, le thread de décodage utilisait 23.8 %, mais le téléphone maintenait sa fréquence d’horloge au minimum de 300 MHz : une simple mise à l’échelle selon le rapport des fréquences donne environ 3 % à fréquence d’horloge maximale.

Sur les téléphones que nous avons testés, la charge écran allumé dépendait davantage de la résolution de l’écran que de la vitesse du CPU (Android 4.x semble redessiner tout l’écran même pour de petites mises à jour). Un téléphone en 1080 × 1920 utilisait environ 4 % sur l’écran de lecture, et un téléphone en 1440 × 3120 sous Android 11 environ 8.5 % (rapporté à l’un de ses 8 cœurs ; environ 1 % de l’ensemble du téléphone). Les anciens téléphones ont de petits écrans et les téléphones haute résolution davantage de puissance de calcul : pour l’instant, la fréquence de rafraîchissement est donc la même sur tous les téléphones.