Note tecniche

reTONE modifica quanto gestisce in base al formato del brano, alla versione di Android e all’uscita. Per i brani PCM, la conversione della frequenza di campionamento avviene al massimo una volta sui percorsi gestiti da reTONE (internamente, una conversione può usare più stadi di filtro) (per il DSD, al massimo una volta dopo lo stadio DSD-PCM). Con il Bluetooth, il telefono e il codec Bluetooth elaborano ulteriormente l’audio dopo questo punto. La riproduzione si basa su MediaPlayer e AudioTrack di Android, e il motore di reTONE (scritto in C) si occupa della decodifica e della conversione prima di essi.

Android 4.x: molti telefoni Android 4.x aprono il thread di uscita della musica a una frequenza fissa come 48 kHz, e i brani a una frequenza diversa, come 44.1 kHz o 96 kHz, vengono ricampionati all’interno del mixer di Android prima della riproduzione. Le app non hanno modo di impedire questa conversione. Inoltre il decoder standard di 4.x può ridurre i FLAC a 24 bit a 16 bit, o non riuscire ad aprire i FLAC a 192 kHz. Per questo su 4.x il motore di reTONE legge tutti i FLAC e i WAV, oltre a DSF, DFF e AIFF, li converte una sola volta alla frequenza di uscita del telefono (il valore di AudioTrack.getNativeOutputSampleRate) e li passa a 16 bit. Il mixer di Android accetta così com’è l’audio a 16 bit alla stessa frequenza, quindi dal lato di Android non avviene alcuna conversione della frequenza di campionamento. Nel ridurre a 16 bit, i valori che 16 bit possono rappresentare esattamente (come l’audio CD passato senza conversione) vengono consegnati invariati; altrimenti reTONE applica il dither TPDF e, quando l’uscita è a 44.1 kHz o 48 kHz, usa il noise shaping a retroazione dell’errore (il filtro a 5 coefficienti con ponderazione E di Lipshitz, Vanderkooy e Wannamaker) per spostare il rumore di quantizzazione verso frequenze meno udibili. Se si verifica clipping, l’errore retroazionato viene limitato a ±4 LSB per evitare oscillazioni. I coefficienti sono stati progettati per 44.1 kHz e si usano anche a 48 kHz. La quantità totale di rumore aumenta, ma viene spostata sulle alte frequenze, dove l’orecchio è meno sensibile. Tuttavia, se imposta il volume di Android sotto il massimo, il mixer di Android arrotonda di nuovo a 16 bit dopo aver applicato il volume, il che riduce il vantaggio del noise shaping. Ciò non vale per i telefoni che regolano il volume via hardware. In ogni caso non avviene alcuna conversione della frequenza di campionamento. MP3, AAC e formati simili passano per il percorso standard di Android anche su 4.x.

Android 5 e successivi (percorsi che passano per il mixer): su Android 10 e versioni successive rientrano qui anche i percorsi che non usano l’uscita diretta. Il mixer di Android di questa generazione accetta il float, quindi il motore di reTONE passa audio float ad AudioTrack senza dither. Sui telefoni con uscita a 16 bit, Android lo arrotonda poi a 16 bit (in questo punto Android non applica dither). I brani FLAC, WAV e ALAC la cui frequenza di campionamento differisce da quella di uscita del telefono verrebbero ricampionati dal mixer di Android se passati così come sono, e i brani oltre i 16 bit verrebbero troncati a 16 bit. Il ricampionatore predefinito di AOSP usa la qualità dinamica media (DYN_MED) quando l’impostazione di qualità (af.resampler.quality) non è definita, e scende a una qualità ancora inferiore quando il carico stimato dei ricampionatori in uso contemporaneamente supera un limite. Sul telefono che abbiamo controllato, questa impostazione non era definita. Il motore di reTONE ricampiona solo i brani che soddisfano queste condizioni, e si può disattivare con l’impostazione “Conversion by reTONE”. I brani a 16 bit alla frequenza di uscita del telefono (come l’audio CD su un telefono a 44.1 kHz) non richiedono conversione, quindi passano per il percorso standard di Android.

Uscita diretta (Android 10 e versioni successive; disponibilità secondo il telefono): la disponibilità dell’“uscita diretta”, che invia l’audio alla frequenza del brano senza passare per il mixer, e dell’“offload”, che decodifica l’audio compresso sul chip, dipende dal telefono e dall’uscita. Su Android 10 e versioni successive, un’app può chiedere al telefono con AudioTrack.isDirectPlaybackSupported se un dato formato, una data frequenza e una data profondità di bit possano essere inviati direttamente all’uscita attuale. reTONE usa questo percorso solo quando il telefono risponde di sì e la politica audio del telefono instrada davvero il PCM verso l’uscita diretta; altrimenti riproduce attraverso il percorso standard di Android. La risposta cambia a seconda dell’uscita, quindi reTONE chiede di nuovo ogni volta che si collegano o scollegano gli auricolari o l’USB. Sui telefoni la cui politica audio instrada il PCM verso l’uscita diretta, i formati principali che non potevano essere inviati direttamente erano il PCM a 16 bit a 44.1, 48 e 88.2 kHz (l’audio CD rientra in questo gruppo). I 24 bit e il float potevano essere inviati direttamente alla frequenza del brano, mentre MP3 e AAC (brani di 60 secondi o più) andavano in offload. Per questo reTONE decodifica l’audio lossless a 16 bit (FLAC, ALAC, WAV) in PCM (ALAC con il decoder proprio di reTONE se il telefono non ne ha uno) e lo passa a MediaPlayer tramite MediaDataSource come WAV a 24 bit con gli 8 bit inferiori riempiti di zeri. I 16 bit superiori restano invariati. Prima di passare a questo percorso, decodifica davvero il primo blocco per verificare che esca PCM a 16 bit autentico, e torna al percorso standard se non riesce a confermarlo. L’audio lossless a 24 bit e ad alta frequenza, e MP3 e AAC, vanno già in uscita diretta od offload, quindi vengono passati così come sono. Le app non hanno modo di leggere quale uscita il telefono abbia effettivamente usato, quindi “DIRECT” nella schermata del lettore è una previsione. In passato reTONE si fidava della sola risposta del telefono, ma Android standard può comunque inviare il PCM al mixer anche quando risponde di sì, e alcuni telefoni mostravano DIRECT quando l’audio non era davvero diretto. Dalla 0.92.48, reTONE controlla anche la politica audio del telefono. Dalla 0.90.1, “DIRECT” compare solo per i brani lossless e mai con il Bluetooth. Con l’offload, inoltre, non possiamo verificare se la frequenza di campionamento cambi all’interno del chip. Su questo percorso gli effetti sonori lato Android non vengono applicati (su alcuni telefoni gli effetti girano dentro il chip), mentre le impostazioni hardware del DAC (come i filtri) restano in vigore. Si può attivare o disattivare nelle impostazioni.

Uscita diretta verso DAC USB: quando collega un DAC USB a un telefono con supporto USB host (OTG), reTONE invia i dati direttamente al DAC senza passare per il percorso audio di Android. Sul telefono che abbiamo verificato, il percorso standard di Android convertiva l’audio a 16 bit/48 kHz per il DAC USB (era aperta anche un’uscita a 32 bit/192 kHz, ma non veniva usata per la musica). L’uscita diretta di reTONE funziona come segue.

• Tramite l’API host USB del telefono, reTONE trova il DAC, ottiene la Sua autorizzazione e legge i descrittori USB (per USB Audio Class 2.0: l’ID del clock, le impostazioni alternative dell’interfaccia di riproduzione, l’endpoint di uscita e l’endpoint di feedback; per la Class 1.0: le frequenze di campionamento e la dimensione dei pacchetti di ciascuna impostazione alternativa).
• Prende il controllo del DAC dal driver di Android (claimInterface) e preferisce un’impostazione alternativa PCM, a 2 canali e 32 bit (24 o 16 bit se non disponibile).
• Legge le frequenze di campionamento supportate con GET RANGE della sorgente di clock. Se la frequenza del brano rientra nell’intervallo, la imposta con SET CUR e la conferma con GET CUR. Solo i brani a frequenze non supportate, o a frequenze che l’USB del telefono si rifiuta di trasportare (dalla 0.92.68), vengono ricampionati, una volta, da reTONE a una frequenza accettata dal DAC. I brani a frequenze supportate dal DAC non subiscono conversione della frequenza di campionamento né dither. I brani fino a 24 bit vengono inviati con i dati originali collocati invariati nei bit alti di una parola a 32 bit (quando si usa il volume del DAC o quando il volume si regola sul DAC stesso). Anche i brani a 32 bit interi seguono un percorso che li mantiene come interi (dalla 0.92.65). Vengono arrotondati solo i valori che la profondità di bit del DAC non può rappresentare esattamente, con dither TPDF quando il DAC è a 24 bit o meno.
• I trasferimenti sono gestiti lato C con trasferimenti isocroni usbdevfs. Per i DAC High Speed che acquisiscono l’audio ogni 0.125 ms (la maggior parte), 1 ms di audio (8 microframe) viene raggruppato in un unico trasferimento, e se ne tengono accodati 64 in anticipo. Per i DAC con un intervallo più lungo, ogni trasferimento contiene 32 pacchetti e se ne accodano meno, mantenendo circa 64 ms di anticipo. I DAC asincroni comunicano dall’endpoint di feedback il numero di frame per microframe, e reTONE adegua la quantità inviata di conseguenza. Il formato di quel valore varia da DAC a DAC, quindi reTONE lo riconosce da ciò che arriva. Quando è reTONE ad applicare il volume, lo fa subito prima dell’invio, quindi le modifiche hanno effetto immediato (ogni modifica viene raccordata in circa 5 ms per evitare scalini bruschi).
• In questo periodo anche MP3, AAC e formati simili vengono decodificati in PCM con il decoder del telefono (MediaCodec) prima dell’invio, quindi reTONE riproduce ogni brano. Scollegando il DAC la riproduzione va in pausa. Quando un’altra app inizia a riprodurre, reTONE va in pausa e restituisce il DAC ad Android, e lo riprende quando riproduce di nuovo in reTONE. Se il DAC non viene restituito ad Android, ad esempio dopo un arresto forzato, reTONE lo restituisce subito dopo un aggiornamento, e quando apre reTONE con “USB DAC direct output” disattivato.

Molti telefoni della generazione Android 4.1 non possono usare un DAC USB come uscita audio, ma l’uscita diretta di reTONE usa solo la funzione host USB, quindi riesce comunque a inviare l’audio. Con il nostro telefono di prova del 2012 (Android 4.1) e un DAC a batteria, 24 bit/192 kHz sono stati riprodotti senza conversione. Abbiamo provato di persona DAC USB Audio Class 2.0. I DAC Class 1.0 sono supportati, ma finora le prove sul campo provengono solo dalle segnalazioni degli utenti. I telefoni più vecchi possono fornire via USB solo una piccola corrente, quindi i DAC alimentati dal bus potrebbero non essere riconosciuti. Abbiamo visto anche un caso in cui le interferenze radio del Wi-Fi raggiungevano il DAC attraverso il cavo USB e causavano un rumore intermittente. La riproduzione non richiede una connessione, quindi consigliamo di passare alla modalità aereo quando si ascolta tramite un DAC USB.

La conversione della frequenza di campionamento ricalcola la forma d’onda tra i campioni originali, quindi la qualità del filtro si riflette direttamente sul suono. Il filtro di reTONE è un filtro FIR ottenuto applicando una finestra di Kaiser a una funzione sinc. Usa una struttura polifase, che divide i coefficienti in gruppi secondo il rapporto di conversione e calcola solo ciò che serve. Il progetto si basa su due criteri: non attenuare il suono udibile e tenere ben soppresso l’aliasing causato dalla conversione.

• Banda passante: piatta fino a 20 kHz (entro ±0.001 dB per progetto; per conversioni tra frequenze di 44.1 kHz o superiori).
• Banda di arresto: inizia da “la frequenza più bassa − 20 kHz”. Tra 44.1 kHz e 48 kHz, cioè 24.1 kHz. L’aliasing che cade in questo intervallo compare sopra i 20 kHz e resta fuori dalla banda udibile (fino a 20 kHz).
• Attenuazione (obiettivo di progetto): 120 dB per i telefoni con uscita float (Android 5 e versioni successive), 100 dB per quelli con uscita a 16 bit (Android 4.x). La lunghezza del filtro e la finestra sono progettate con un margine di 2 dB sull’obiettivo, così il valore calcolato supera l’obiettivo per ogni conversione (per 44.1 → 48 kHz, i valori calcolati sono circa 122 dB e circa 102 dB). L’aliasing residuo a −100 dB è ben al di sotto del rumore di fondo a 16 bit (circa −93 dBFS su tutta la banda, dither compreso), quindi un’attenuazione di 100 dB non è udibilmente diversa da 120 dB.
• Tap: determinati dall’attenuazione e dalla banda di transizione con la formula della finestra di Kaiser (86 tap per 44.1 ↔ 48 kHz a 120 dB).
• Stadi 2:1: gli stadi che dimezzano esattamente la frequenza, come 96 → 48 kHz, usano un filtro half-band, in cui metà dei coefficienti è zero e il resto è simmetrico, riducendo le moltiplicazioni a circa un quarto di un filtro normale. 192 → 48 kHz usa due stadi half-band, e i rapporti rimanenti come 88.2 → 48 kHz sono gestiti da un filtro polifase.

Nelle misure, i segnali a 1 kHz, 19 kHz e 19.9 kHz sono usciti allo stesso livello entro 0.01 dB. Con un ingresso a 30 kHz, l’aliasing comparso tra 0 e 20 kHz era almeno 104.6 dB sotto il segnale originale con uscita a 44.1 kHz e 48 kHz, e almeno 116 dB sotto per la conversione da 192 kHz (misurato prima dell’arrotondamento a 16 bit). Questi sono valori a una singola frequenza. Per progetto, l’intera banda di arresto viene soppressa almeno fino agli obiettivi di attenuazione indicati sopra.

Poiché la conversione crea nuovi punti tra i campioni originali, i brani con livello alto possono ritrovarsi con punti oltre 0 dBFS. Convertendo a 48 kHz diverse registrazioni commerciali in nostro possesso, i punti oltre 0 dBFS costituivano lo 0.0001–0.001% del totale, con massimi da +0.38 a +0.59 dB. Questi vengono tagliati con l’uscita a 16 bit o nel mixer del telefono, quindi durante il ricampionamento, e solo allora, reTONE abbassa il livello di 1 dB, lasciando un margine oltre il massimo misurato. I brani che non vengono ricampionati restano invariati, quindi sullo stesso telefono i brani ricampionati suonano 1 dB più piano. Passando senza interruzioni al brano successivo, lo stato del ricampionatore viene riportato avanti, così l’inizio e la fine dei brani non vengono tagliati dall’elaborazione (dalla 0.92.57).

Il volume non viene applicato all’interno del motore di reTONE. Viene applicato nel mixer di Android (il volume di AudioTrack). Applicarlo all’interno del motore ritarderebbe le modifiche finché non finisce di suonare il circa mezzo secondo (500 ms) di audio accumulato in AudioTrack, rendendo lenta la risposta dei tasti del volume. Sui telefoni con uscita a 16 bit, abbassando il volume Android arrotonda di nuovo a 16 bit (in questo punto Android non applica dither).

I calcoli sono scritti in C e usano le istruzioni ARM NEON per elaborare insieme i canali sinistro e destro. Il ciclo interno del filtro legge i coefficienti come vettori e usa quattro accumulatori per nascondere la latenza. Anche il dither, compresi numeri casuali, arrotondamento, clipping e retroazione dell’errore, avviene interamente in NEON, evitando i trasferimenti tra NEON e registri generici, che sono lenti sui core più vecchi (Cortex-A9). Le build Intel (x86) usano un percorso in C semplice senza NEON. I valori di carico riportati sotto provengono dai telefoni ARM che abbiamo provato.

Ci sono tre punti in cui abbassare il volume: ① dentro reTONE, applicato ai dati (digitale), ② il volume digitale interno del DAC, controllato via USB, e ③ la manopola o i tasti sul DAC stesso. Quale viene usato dipende dal metodo di regolazione scelto quando collega il DAC per la prima volta e dal fatto che il DAC supporti o meno il controllo del volume via USB.

② Volume via USB: la USB Audio Class prevede un meccanismo per il volume chiamato Feature Unit, e GET RANGE ne legge minimo, massimo e passo (in unità di 1/256 dB). reTONE converte in dB il proprio volume (un unico guadagno che combina i livelli di Android e il volume fine). Se rientra in questo intervallo, reTONE lo invia al DAC e mantiene al massimo la propria uscita. Solo quando il volume scende sotto l’intervallo, la differenza viene applicata al PCM con ①. 0 è il silenzio.

① Dentro reTONE: per i DAC senza volume Feature Unit, e per i DAC impostati su “reTONE adjusts”, reTONE applica il volume ai dati prima di inviarli, raccordando ogni modifica in circa 5 ms. Viene applicato subito prima dell’invio, quindi i tasti del volume rispondono immediatamente.

③ Il DAC stesso: se il DAC ha un proprio controllo del volume non si può leggere via USB. Per questo, la prima volta che collega un DAC, reTONE Le chiede una sola volta come regolare il volume del DAC, con tre scelte: “On the DAC itself”, “Volume keys (DAC adjusts)” e “Volume keys (reTONE adjusts)”. Alcuni DAC dichiarano di aver accettato un comando di volume senza cambiarlo davvero; per questi, scegliendo “reTONE adjusts” il volume del DAC viene fissato al massimo e abbassato con ①. Se sceglie “On the DAC”, sia ② sia ① restano fissi al massimo e premere i tasti del volume non cambia nulla (un messaggio lo segnala). Con i DAC dotati di controllo del volume analogico, evitare l’attenuazione digitale permette di sfruttare al meglio il DAC. La scelta viene memorizzata per ogni modello di DAC (ID del produttore e ID del prodotto USB) e si può cambiare con l’impostazione “DAC volume”.

Quando è scelto “On the DAC”, oppure quando si usa il volume del DAC (entro il suo intervallo di volume), i brani a frequenze supportate dal DAC vengono inviati senza modificare i dati. Solo quando imposta il volume sotto l’intervallo del DAC, reTONE applica la parte restante. In questo caso, se il brano è lossless (compreso il DSD nativo) e la sua profondità di bit rientra in quella del DAC, la schermata del percorso del segnale mostra BIT-PERFECT (i brani a 32 bit interi solo se seguono il percorso intero). Ciò che avviene dentro il DAC non si può verificare.

I brani DSF e DFF vengono inviati come DSD, senza conversione in PCM, solo quando il DAC supporta il DSD nativo e il suo volume si può controllare via USB (e il DAC non è impostato su “reTONE adjusts”). reTONE non può modificare il volume del DSD stesso, quindi è necessario il controllo del volume lato DAC. La schermata del lettore mostra qualcosa come “DSD64 → USB AUDIO • DSD64 DIRECT”.

Viene inviato come segue.

• Il DSD nativo funziona con i DAC i cui descrittori USB includono un’impostazione alternativa per i dati grezzi (TYPE I RAW DATA).
• I bit del DSD vengono impacchettati 4 byte alla volta in una parola a 32 bit per canale, con il bit più vecchio in cima. Il DSF memorizza i bit partendo dal meno significativo, quindi l’ordine dei bit in ogni byte viene invertito prima dell’impacchettamento. Le parole vengono inviate in big-endian (la stessa ipotesi del DSD_U32_BE di Linux). Questo reimpacchettamento è fatto in C, e il buffer circolare di trasferimento contiene circa 500 ms.
• Il clock del DAC è impostato su “frequenza DSD ÷ 32” (88.2 kHz per DSD64, 176.4 kHz per DSD128).
• Silenzi, pause e fine dei brani vengono riempiti con lo schema di silenzio DSD 0x69.

Questo ordine dei byte e dei bit è stato verificato con una riproduzione corretta sul DAC che abbiamo provato. Non è ancora stato controllato con altri DAC, e il DoP (DSD over PCM) non è supportato. Non si possono leggere nemmeno i DFF compressi in DST.

Sending DSD (impostazione): “Sending DSD” compare sotto “Sound” nelle impostazioni solo mentre è collegato un DAC in grado di usare il DSD nativo. L’impostazione predefinita è “Send as DSD” (il DAC riproduce direttamente il DSD), e può passare a “Convert to PCM” (reTONE lo converte in PCM). Se i brani DSD si interrompono, o se preferisce la riproduzione in PCM, scelga la conversione in PCM. La scelta viene memorizzata per ogni modello di DAC, e il cambio riapre il brano corrente nella stessa posizione. Abbiamo trovato un DAC che si interrompeva per un istante con registrazioni DSD la cui modulazione superava il livello di riferimento del 50%. Il trasferimento era normale, quindi sembra dipendere dal progetto del DAC. Anche in quel caso la conversione in PCM evita le interruzioni.

Conversione DSD → PCM: quando il DSD nativo non è usato (con DAC che non soddisfano le condizioni, quando è scelto “Convert to PCM”, e per l’uscita verso Bluetooth, auricolari o altoparlante), reTONE converte il DSD in PCM in due fasi.

• Fase 1: il flusso di bit DSD viene decimato di un fattore 32, 64 e così via in PCM a circa 88.2 kHz o più (DSD64 di 32 a 88.2 kHz, DSD128 di 64 a 88.2 kHz). Il filtro è un FIR con finestra di Kaiser. La banda passante arriva al maggiore tra 20 kHz e un quarto della frequenza di uscita, la banda di arresto inizia da “frequenza di uscita − banda passante”, e l’attenuazione è di 100 dB per l’uscita a 16 bit e 110 dB per float e USB. Il numero di coefficienti è determinato dalla formula della finestra di Kaiser. Il calcolo usa consultazioni di tabelle a 16 bit, e le tabelle vengono costruite una volta per configurazione e riutilizzate. Nelle misure, la risposta a 20 kHz era 0.000 dB e l’aliasing sotto i 20 kHz era −101 dB (progetto a 100 dB) / da −110 a −117 dB (progetto a 110 dB).
• Fase 2: se necessario, lo stesso ricampionatore descritto nella sezione sui filtri converte una sola volta alla frequenza di uscita del telefono (ad esempio 44.1 kHz o 48 kHz per l’uscita integrata).
• Livello: convertito in modo che lo 0 dB SACD (modulazione al 50%) diventi −6 dBFS (una convenzione diffusa; dalla 0.69.0. Le versioni precedenti usavano −12 dBFS e suonavano 6 dB più piano).

Quando invia PCM a un DAC USB, reTONE invia il PCM a “frequenza DSD ÷ 32” (88.2 kHz per DSD64, 176.4 kHz per DSD128, 352.8 kHz per DSD256) così com’è, senza la conversione della fase 2, se il DAC lo supporta. Poiché il DSD viene convertito in PCM, in questo caso DIRECT non compare.

reTONE punta a “non fare nulla quando è fermo” e a “non disegnare nulla durante la riproduzione a schermo spento”. Le attività periodiche avvengono solo durante la riproduzione: ogni secondo a schermo acceso e ogni 5 secondi a schermo spento, e la barra di avanzamento nella schermata del lettore ridisegna solo sé stessa ogni 250 ms. Orologio e batteria si aggiornano tramite notifiche del sistema, senza interrogazioni periodiche.

Uso della CPU da parte di reTONE, rispetto a un core, sul nostro telefono di prova del 2012 (Android 4.1, Cortex-A9 a 2 core).

• Fermo: 0%.
• In riproduzione a schermo spento: il disegno si ferma. I brani riprodotti con la riproduzione standard di Android usano quasi lo 0%, mentre quelli riprodotti dal motore di reTONE (FLAC, WAV e altri su Android 4.x) aggiungono il carico di decodifica e conversione indicato sotto.
• In riproduzione con la schermata del lettore visibile: circa 2% (misurato durante la riproduzione reale; soprattutto il ridisegno della barra di avanzamento, decodifica esclusa).
• Il motore di reTONE che emette l’audio CD (16 bit/44.1 kHz) così com’è a 44.1 kHz: circa 2%. Con conversione a 48 kHz in uscita: circa 4%.
• Conversione da 24 bit/96 kHz a 48 kHz: circa 5%. A 44.1 kHz: circa 7%.
• Conversione da 24 bit/192 kHz a 44.1 kHz: da circa 10% (solo calcolo) a circa 15% (stima approssimativa del carico totale di riproduzione, riportata al clock massimo).
• Invio di 24 bit/192 kHz a un DAC USB senza conversione: circa 20% (misurato durante la riproduzione reale, schermo acceso, thread di trasferimento incluso).

I valori del motore da “audio CD” a “24 bit/192 kHz” derivano dall’esecuzione degli stessi calcoli a piena velocità al clock massimo, convertiti in percentuale del tempo reale. Durante la riproduzione reale il telefono abbassa il clock tra 200 MHz e 1 GHz, quindi i valori mostrati sul telefono sembrano da 2 a 3 volte più alti (20–29% per 24 bit/192 kHz). Anche il modo in cui è scritto il codice fa una grande differenza: l’attuale implementazione in C e NEON aveva da un terzo a un quinto del carico di un primo prototipo scritto in Java.

Per la conversione da DSD a PCM, con quel telefono del 2012 e un DAC a batteria, convertire DSD64 in PCM a 88.2 kHz e inviarlo via USB richiedeva circa l’11.8% per la conversione e circa il 5.8% per il trasferimento USB (a circa 1 GHz). Quando DSD64 veniva riprodotto tramite l’uscita integrata (48 kHz) su un telefono Android 4.4, il thread di decodifica usava il 23.8%, ma il telefono manteneva il clock al minimo di 300 MHz, quindi, riportando semplicemente in proporzione al clock, si ottiene circa il 3% al clock massimo.

Sui telefoni che abbiamo provato, il carico a schermo acceso dipendeva più dalla risoluzione dello schermo che dalla velocità della CPU (Android 4.x sembra ridisegnare l’intero schermo anche per piccoli aggiornamenti). Un telefono 1080 × 1920 usava circa il 4% nella schermata del lettore, e un telefono 1440 × 3120 con Android 11 circa l’8.5% (rispetto a uno dei suoi 8 core; circa l’1% dell’intero telefono). I telefoni più vecchi hanno schermi piccoli e quelli ad alta risoluzione hanno più potenza di calcolo, quindi per ora la frequenza di ridisegno è la stessa su tutti i telefoni.