Notas técnicas

reTONE se encarga de más o de menos según el formato de la pista, la versión de Android y la salida. En las pistas PCM, la conversión de frecuencia de muestreo se realiza como máximo una vez en las rutas que gestiona reTONE (internamente, una conversión puede usar varias etapas de filtro) (en DSD, como máximo una vez después de la etapa de DSD a PCM). Con Bluetooth, el móvil y el códec Bluetooth procesan el audio todavía más después de esto. La reproducción se apoya en MediaPlayer y AudioTrack de Android, y el motor de reTONE (escrito en C) se ocupa de la decodificación y la conversión antes de ellos.

Android 4.x: Muchos móviles con Android 4.x abren el hilo de salida de música a una frecuencia fija, como 48 kHz, y las pistas a otra frecuencia, como 44.1 kHz o 96 kHz, se remuestrean dentro del mezclador de Android antes de reproducirse. Las aplicaciones no tienen forma de impedir esta conversión. Además, el decodificador estándar de 4.x puede reducir a 16 bit los FLAC de 24 bit, o no llegar a abrir los FLAC de 192 kHz. Por eso, en 4.x el motor de reTONE lee todos los FLAC y WAV, así como los DSF, DFF y AIFF, los convierte una sola vez a la frecuencia de salida del móvil (el valor de AudioTrack.getNativeOutputSampleRate) y los entrega en 16 bit. El mezclador de Android acepta tal cual el audio de 16 bit a la misma frecuencia, así que en el lado de Android no se produce ninguna conversión de frecuencia de muestreo. Al reducir a 16 bit, los valores que 16 bit pueden representar con exactitud (como el audio de CD que pasa sin conversión) se entregan sin cambios; en los demás casos, reTONE aplica dither TPDF y, cuando la salida es de 44.1 kHz o 48 kHz, usa modelado de ruido con realimentación del error (el filtro de 5 coeficientes con ponderación E de Lipshitz, Vanderkooy y Wannamaker) para llevar el ruido de cuantización a frecuencias menos audibles. Si se produce recorte, el error realimentado se limita a ±4 LSB para evitar oscilaciones. Los coeficientes se diseñaron para 44.1 kHz y también se usan a 48 kHz. La cantidad total de ruido aumenta, pero se desplaza a frecuencias altas, donde el oído es menos sensible. Sin embargo, si ajusta el volumen de Android por debajo del máximo, el mezclador de Android vuelve a redondear a 16 bit después de aplicar el volumen, lo que reduce el beneficio del modelado de ruido. Esto no ocurre en los móviles que ajustan el volumen por hardware. En cualquier caso, no se produce ninguna conversión de frecuencia de muestreo. MP3, AAC y formatos similares se reproducen por la ruta estándar de Android incluso en 4.x.

Android 5 y posteriores (rutas que pasan por el mezclador): En Android 10 y posteriores, las rutas que no usan la salida directa también entran aquí. El mezclador de Android de esta generación acepta coma flotante, así que el motor de reTONE pasa audio en coma flotante a AudioTrack sin dither. En móviles con salida de 16 bit, Android lo redondea después a 16 bit (Android no aplica dither en este punto). Las pistas FLAC, WAV y ALAC cuya frecuencia de muestreo difiere de la frecuencia de salida del móvil serían remuestreadas por el mezclador de Android si se pasaran tal cual, y las pistas de más de 16 bit se truncarían a 16 bit. El remuestreador predeterminado de AOSP usa calidad dinámica media (DYN_MED) cuando el ajuste de calidad (af.resampler.quality) no está definido, y baja a una calidad aún menor cuando la carga estimada de los remuestreadores en uso a la vez supera un límite. En el móvil que comprobamos, este ajuste no estaba definido. El motor de reTONE remuestrea solo las pistas que cumplen estas condiciones, y puede desactivarlo con el ajuste “Conversion by reTONE”. Las pistas de 16 bit a la frecuencia de salida del móvil (como el audio de CD en un móvil de 44.1 kHz) no necesitan conversión, así que se reproducen por la ruta estándar de Android.

Salida directa (Android 10 y posteriores; la disponibilidad depende del móvil): La disponibilidad de la “salida directa”, que envía el audio a la frecuencia de la pista sin pasar por el mezclador, y del “offload”, que decodifica el audio comprimido en el chip, depende del móvil y de la salida. En Android 10 y posteriores, una aplicación puede preguntar al móvil con AudioTrack.isDirectPlaybackSupported si un formato, una frecuencia y una profundidad de bits determinados se pueden enviar directamente a la salida actual. reTONE usa esta ruta solo cuando el móvil responde que sí y la política de audio del móvil encamina realmente el PCM a la salida directa; en caso contrario, reproduce por la ruta estándar de Android. La respuesta cambia según la salida, así que reTONE vuelve a preguntar cada vez que se conectan o desconectan auriculares o USB. En los móviles cuya política de audio encamina el PCM a la salida directa, los principales formatos que no se podían enviar directamente eran el PCM de 16 bit a 44.1, 48 y 88.2 kHz (el audio de CD entra en este grupo). El de 24 bit y el de coma flotante se podían enviar directamente a la frecuencia de la pista, y el MP3 y el AAC (pistas de 60 segundos o más) iban a offload. Por eso reTONE decodifica el audio sin pérdida de 16 bit (FLAC, ALAC, WAV) a PCM (ALAC con el decodificador propio de reTONE si el móvil no tiene uno) y lo pasa a MediaPlayer mediante MediaDataSource como un WAV de 24 bit con los 8 bit inferiores rellenos de ceros. Los 16 bit superiores no cambian. Antes de cambiar, decodifica realmente el primer bloque para confirmar que sale PCM de 16 bit auténtico, y vuelve a la ruta estándar si no puede confirmarlo. El audio sin pérdida de 24 bit o de frecuencia alta, y el MP3 y el AAC, ya van a la salida directa o al offload, así que se pasan tal cual. Las aplicaciones no tienen forma de leer qué salida usó realmente el móvil, por lo que “DIRECT” en la pantalla del reproductor es una expectativa. reTONE se basaba antes solo en la respuesta del móvil, pero el Android estándar puede seguir enviando PCM al mezclador incluso cuando responde que sí, y algunos móviles mostraban DIRECT cuando el audio no era realmente directo. Desde la 0.92.48, reTONE comprueba además la política de audio del móvil. Desde la 0.90.1, “DIRECT” se muestra solo en las pistas sin pérdida, y nunca por Bluetooth. Con el offload, tampoco podemos comprobar si la frecuencia de muestreo cambia dentro del chip. En esta ruta no se aplican los efectos de sonido del lado de Android (en algunos móviles, los efectos se ejecutan dentro del chip), mientras que los ajustes de hardware del DAC (como los filtros) siguen aplicándose. Se puede activar o desactivar en los ajustes.

Salida directa a DAC USB: Al conectar un DAC USB a un móvil con función de host USB (OTG), reTONE envía los datos directamente al DAC sin pasar por la ruta de audio de Android. En el móvil que comprobamos, la ruta estándar de Android convertía el audio a 16 bit/48 kHz para el DAC USB (también había abierta una salida de 32 bit/192 kHz, pero no se usaba para la música). La salida directa de reTONE funciona así.

• Mediante la API de host USB del móvil, reTONE encuentra el DAC, obtiene su permiso y lee los descriptores USB (en USB Audio Class 2.0: el ID del reloj, las configuraciones alternativas de la interfaz de reproducción, el endpoint de salida y el endpoint de realimentación; en Class 1.0: las frecuencias de muestreo y el tamaño de paquete de cada configuración alternativa).
• Toma el control del DAC quitándoselo al controlador de Android (claimInterface) y prefiere un ajuste alternativo PCM, de 2 canales y 32 bit (24 o 16 bit si no está disponible).
• Lee las frecuencias de muestreo admitidas con GET RANGE de la fuente de reloj. Si la frecuencia de la pista está dentro del rango, la fija con SET CUR y la confirma con GET CUR. Solo las pistas a frecuencias no admitidas, o a frecuencias que el USB del móvil se niega a transportar (desde la 0.92.68), las remuestrea reTONE, una sola vez, a una frecuencia que acepte el DAC. Las pistas a frecuencias que admite el DAC no reciben conversión de frecuencia de muestreo ni dither. Las pistas de hasta 24 bit se envían con los datos originales colocados sin cambios en los bits superiores de una palabra de 32 bit (al usar el volumen del DAC o al ajustar el volumen en el propio DAC). Las pistas de 32 bit enteras siguen además una ruta que las mantiene como enteros (desde la 0.92.65). Solo se redondean los valores que la profundidad de bits del DAC no puede representar con exactitud, con dither TPDF cuando el DAC es de 24 bit o menos.
• Las transferencias se gestionan en el lado de C con transferencias isócronas de usbdevfs. En los DAC High Speed que reciben audio cada 0.125 ms (la mayoría), 1 ms de audio (8 microtramas) se agrupa en una transferencia, y se mantienen 64 de ellas en cola por adelantado. En los DAC con un intervalo más largo, cada transferencia contiene 32 paquetes y se ponen menos en cola, manteniendo unos 64 ms de adelanto. Los DAC asíncronos comunican el número de tramas por microtrama desde el endpoint de realimentación, y reTONE ajusta cuánto envía en consecuencia. El formato de ese valor varía según el DAC, así que reTONE lo detecta a partir de lo que llega. Cuando reTONE aplica el volumen, lo hace justo antes de enviar, por lo que los cambios surten efecto de inmediato (cada cambio se suaviza durante unos 5 ms para evitar saltos bruscos).
• Durante este tiempo, el MP3, el AAC y formatos similares también se decodifican a PCM con el decodificador del móvil (MediaCodec) antes de enviarlos, de modo que reTONE reproduce todas las pistas. Al desconectar el DAC, la reproducción se pausa. Cuando otra aplicación empieza a reproducir, reTONE se pausa y devuelve el DAC a Android, y lo recupera cuando vuelve a reproducir en reTONE. Si el DAC no se devuelve a Android, por ejemplo tras un cierre forzado, reTONE lo devuelve justo después de una actualización y cuando abre reTONE con “USB DAC direct output” desactivado.

Muchos móviles de la generación de Android 4.1 no pueden usar un DAC USB como salida de audio, pero la salida directa de reTONE usa solo la función de host USB, así que aun así puede enviar audio. Con nuestro móvil de pruebas de 2012 (Android 4.1) y un DAC con batería, el audio de 24 bit/192 kHz se reprodujo sin conversión. Hemos probado nosotros mismos DAC USB Audio Class 2.0. Los DAC Class 1.0 también se admiten, pero hasta ahora las pruebas reales proceden solo de informes de usuarios. Los móviles antiguos solo pueden suministrar una corriente pequeña por USB, por lo que es posible que los DAC alimentados por el bus no se reconozcan. También hemos visto un caso en el que la interferencia de las ondas de Wi-Fi llegó al DAC a través del cable USB y provocó ruido intermitente. La reproducción no necesita conexión, por lo que recomendamos activar el modo avión al escuchar con un DAC USB.

La conversión de frecuencia de muestreo recalcula la forma de onda entre las muestras originales, así que la calidad del filtro se refleja directamente en el sonido. El filtro de reTONE es un filtro FIR creado aplicando una ventana de Kaiser a una función sinc. Usa una estructura polifásica, que divide los coeficientes en grupos según la relación de conversión y calcula solo lo necesario. El diseño se basa en dos criterios: no atenuar el sonido audible y mantener bien suprimido el aliasing que causa la conversión.

• Banda de paso: plana hasta 20 kHz (dentro de ±0.001 dB por diseño; para conversiones entre frecuencias de 44.1 kHz o superiores).
• Banda de rechazo: empieza en "la frecuencia menor − 20 kHz". Entre 44.1 kHz y 48 kHz, eso es 24.1 kHz. El aliasing que cae en este rango aparece por encima de 20 kHz y queda fuera de la banda audible (hasta 20 kHz).
• Atenuación (objetivo de diseño): 120 dB para móviles con salida en coma flotante (Android 5 y posteriores), 100 dB para móviles con salida de 16 bit (Android 4.x). La longitud del filtro y la ventana se diseñan con un margen de 2 dB sobre el objetivo, para que el valor calculado supere el objetivo en todas las conversiones (para 44.1 → 48 kHz, los valores calculados son de unos 122 dB y unos 102 dB). El aliasing residual a −100 dB queda muy por debajo del suelo de ruido de 16 bit (alrededor de −93 dBFS en toda la banda, dither incluido), así que 100 dB de atenuación no se distinguen de oído de 120 dB.
• Coeficientes (taps): se determinan a partir de la atenuación y la banda de transición con la fórmula de la ventana de Kaiser (86 coeficientes para 44.1 ↔ 48 kHz a 120 dB).
• Etapas 2:1: las etapas que reducen la frecuencia exactamente a la mitad, como 96 → 48 kHz, usan un filtro de media banda (half-band), en el que la mitad de los coeficientes son cero y el resto son simétricos, lo que reduce las multiplicaciones a una cuarta parte aproximadamente de las de un filtro normal. 192 → 48 kHz usa dos etapas de media banda, y las relaciones restantes, como 88.2 → 48 kHz, las gestiona un filtro polifásico.

En las mediciones, señales de 1 kHz, 19 kHz y 19.9 kHz salieron con el mismo nivel con una diferencia inferior a 0.01 dB. Con una entrada de 30 kHz, el aliasing que aparece en 0–20 kHz quedó al menos 104.6 dB por debajo de la señal original con salida de 44.1 kHz y 48 kHz, y al menos 116 dB por debajo en la conversión desde 192 kHz (medido antes de redondear a 16 bit). Son valores a una sola frecuencia. Por diseño, toda la banda de rechazo se suprime al menos hasta los objetivos de atenuación indicados arriba.

Como la conversión crea puntos nuevos entre las muestras originales, las pistas con mucho nivel pueden acabar con puntos por encima de 0 dBFS. Al convertir a 48 kHz varias grabaciones comerciales que teníamos, los puntos por encima de 0 dBFS representaron entre el 0.0001 % y el 0.001 % del total, con máximos de +0.38 a +0.59 dB. Estos se recortan en la salida de 16 bit o en el mezclador del móvil, así que, al remuestrear, y solo entonces, reTONE baja el nivel 1 dB, dejando margen por encima del máximo medido. Las pistas que no se remuestrean se dejan sin cambios, de modo que, en el mismo móvil, las pistas remuestreadas suenan 1 dB más bajas. Al pasar sin pausas a la pista siguiente, el estado del remuestreador se mantiene, así que el principio y el final de las pistas no se recortan por el procesamiento (desde la 0.92.57).

El volumen no se aplica dentro del motor de reTONE. Se aplica en el mezclador de Android (el volumen de AudioTrack). Aplicarlo dentro del motor retrasaría los cambios hasta que terminaran de sonar los unos 500 ms de audio almacenados en el búfer de AudioTrack, y las teclas de volumen responderían con lentitud. En móviles con salida de 16 bit, bajar el volumen hace que Android vuelva a redondear a 16 bit (Android no aplica dither en este punto).

Los cálculos están escritos en C y usan instrucciones ARM NEON para procesar a la vez los canales izquierdo y derecho. El bucle interno del filtro lee los coeficientes como vectores y usa cuatro acumuladores para ocultar la latencia. El dither, incluidos los números aleatorios, el redondeo, el recorte y la realimentación del error, también se realiza por completo en NEON, evitando las transferencias entre NEON y los registros de propósito general, que son lentas en núcleos antiguos (Cortex-A9). Las compilaciones para Intel (x86) usan una ruta en C simple, sin NEON. Las cifras de carga que figuran a continuación proceden de los móviles ARM que probamos.

Hay tres puntos en los que bajar el volumen: ① dentro de reTONE, aplicado a los datos (digital), ② el volumen digital interno del DAC, controlado por USB, y ③ la rueda o los botones del propio DAC. Cuál se usa depende del método de ajuste que elija al conectar el DAC por primera vez y de si el DAC admite el control de volumen por USB.

② Volumen por USB: USB Audio Class tiene un mecanismo de volumen llamado Feature Unit, y GET RANGE lee su mínimo, su máximo y el tamaño del paso (en unidades de 1/256 dB). reTONE convierte su volumen (una única ganancia que combina los pasos de Android y el volumen fino) a dB. Si queda dentro de este rango, reTONE lo envía al DAC y mantiene su propia salida al máximo. Solo cuando el volumen baja por debajo del rango se aplica la diferencia al PCM con ①. 0 es silencio.

① Dentro de reTONE: En los DAC sin volumen de Feature Unit, y en los DAC configurados en “reTONE adjusts”, reTONE aplica el volumen a los datos antes de enviarlos, suavizando cada cambio durante unos 5 ms. Se aplica justo antes de enviar, así que las teclas de volumen responden de inmediato.

③ El propio DAC: Por USB no se puede saber si el DAC tiene su propio control de volumen. Por eso, la primera vez que conecta un DAC, reTONE le pregunta una vez cómo debe ajustarse el volumen del DAC, con tres opciones: “On the DAC itself”, “Volume keys (DAC adjusts)” y “Volume keys (reTONE adjusts)”. Algunos DAC indican que aceptaron una orden de volumen sin cambiar realmente el volumen; en esos casos, elegir “reTONE adjusts” fija el volumen del DAC al máximo y lo baja con ①. Si elige “On the DAC”, tanto ② como ① se fijan al máximo y, al pulsar las teclas de volumen, no cambia nada (un mensaje se lo indica). En los DAC con control de volumen analógico, evitar la atenuación digital permite sacar el máximo partido al DAC. La elección se recuerda para cada modelo de DAC (ID de fabricante e ID de producto USB) y se puede cambiar con el ajuste “DAC volume”.

Cuando se elige “On the DAC”, o cuando se usa el volumen del DAC (dentro del rango de volumen del DAC), las pistas a frecuencias que admite el DAC se envían sin cambiar los datos. Solo cuando ajusta el volumen por debajo del rango del DAC, reTONE aplica el resto. En ese caso, si la pista es sin pérdida (incluido el DSD nativo) y su profundidad de bits cabe en la del DAC, la pantalla de la ruta de la señal muestra BIT-PERFECT (las pistas de 32 bit enteras, solo cuando siguen la ruta de enteros). Lo que ocurre dentro del DAC no se puede comprobar.

Las pistas DSF y DFF se envían como DSD, sin conversión a PCM, solo cuando el DAC admite DSD nativo y su volumen se puede controlar por USB (y el DAC no está en “reTONE adjusts”). reTONE no puede cambiar el volumen del propio DSD, por lo que se necesita el control de volumen en el lado del DAC. La pantalla del reproductor muestra algo como “DSD64 → USB AUDIO • DSD64 DIRECT”.

Se envía de la siguiente manera.

• El DSD nativo funciona con los DAC cuyos descriptores USB incluyen un ajuste alternativo para datos sin procesar (TYPE I RAW DATA).
• Los bits DSD se empaquetan de 4 bytes en 4 bytes en una palabra de 32 bit por canal, con el bit más antiguo arriba. DSF almacena los bits con el LSB primero, por lo que el orden de bits de cada byte se invierte antes de empaquetar. Las palabras se envían en big-endian (la misma suposición que DSD_U32_BE de Linux). Este reempaquetado se hace en C, y el búfer circular de transferencia contiene unos 500 ms.
• El reloj del DAC se fija en “frecuencia DSD ÷ 32” (88.2 kHz para DSD64, 176.4 kHz para DSD128).
• Los silencios, las pausas y los finales de pista se rellenan con el patrón de silencio DSD 0x69.

Este orden de bytes y de bits se verificó con una reproducción correcta en el DAC que probamos. Todavía no se ha comprobado con otros DAC, y DoP (DSD over PCM) no es compatible. Tampoco se pueden leer los DFF con compresión DST.

Sending DSD (ajuste): “Sending DSD” aparece en “Sound” en los ajustes solo mientras hay conectado un DAC que puede usar DSD nativo. El valor predeterminado es “Send as DSD” (el DAC reproduce DSD directamente), y puede cambiar a “Convert to PCM” (reTONE lo convierte a PCM). Si las pistas DSD se cortan, o si prefiere la reproducción en PCM, elija convertir a PCM. La elección se recuerda para cada modelo de DAC, y al cambiarla se vuelve a abrir la pista actual en la misma posición. Encontramos un DAC que se cortaba brevemente con grabaciones DSD cuya modulación superaba el nivel de referencia del 50%. La transferencia era normal, así que parece deberse al diseño del DAC. Convertir a PCM evita los cortes también en ese caso.

Conversión de DSD → PCM: cuando no se usa DSD nativo (con DAC que no cumplen las condiciones, cuando se elige “Convert to PCM”, y para la salida a Bluetooth, auriculares o el altavoz), reTONE convierte DSD a PCM en dos etapas.

• Etapa 1: el flujo de bits DSD se diezma por un factor de 32, 64, etc., a PCM de unos 88.2 kHz o más (DSD64 por 32 a 88.2 kHz, DSD128 por 64 a 88.2 kHz). El filtro es un FIR con ventana de Kaiser. La banda de paso llega hasta el mayor valor entre 20 kHz y una cuarta parte de la frecuencia de salida, la banda de rechazo empieza en “frecuencia de salida − banda de paso”, y la atenuación es de 100 dB para la salida de 16 bit y de 110 dB para coma flotante y USB. El número de coeficientes se determina con la fórmula de la ventana de Kaiser. El cálculo usa consultas a tablas de 16 bit, y las tablas se construyen una vez por configuración y se reutilizan. En las mediciones, la respuesta a 20 kHz fue de 0.000 dB, y el aliasing por debajo de 20 kHz fue de −101 dB (diseño de 100 dB) / −110 a −117 dB (diseño de 110 dB).
• Etapa 2: si es necesario, el mismo remuestreador descrito en la sección del filtro convierte una vez a la frecuencia de salida del móvil (como 44.1 kHz o 48 kHz en la salida integrada).
• Nivel: se convierte de modo que 0 dB de SACD (modulación del 50%) pase a ser −6 dBFS (una convención habitual; desde 0.69.0. Las versiones anteriores usaban −12 dBFS y sonaban 6 dB más bajas).

Al enviar PCM a un DAC USB, reTONE envía tal cual PCM a “frecuencia DSD ÷ 32” (88.2 kHz para DSD64, 176.4 kHz para DSD128, 352.8 kHz para DSD256), sin la conversión de la etapa 2, si el DAC lo admite. Como DSD se convierte a PCM, en este caso no se muestra DIRECT.

reTONE se propone “no hacer nada cuando está detenido” y “no dibujar nada mientras reproduce con la pantalla apagada”. El trabajo periódico solo se ejecuta durante la reproducción: cada segundo con la pantalla encendida y cada 5 segundos con ella apagada, y la barra de progreso de la pantalla del reproductor solo se redibuja a sí misma cada 250 ms. El reloj y la batería se actualizan mediante notificaciones del sistema, sin sondeo.

Uso de CPU de reTONE respecto a un núcleo en nuestro móvil de pruebas de 2012 (Android 4.1, Cortex-A9 de 2 núcleos).

• Detenido: 0%.
• Reproduciendo con la pantalla apagada: el dibujado se detiene. Las pistas que se reproducen con la reproducción estándar de Android usan casi un 0%, mientras que las que reproduce el motor de reTONE (FLAC, WAV y otros en Android 4.x) añaden la carga de decodificación y conversión que se indica a continuación.
• Reproduciendo con la pantalla del reproductor visible: aprox. 2% (medido durante la reproducción real; sobre todo el redibujado de la barra de progreso, sin incluir la decodificación).
• El motor de reTONE emitiendo audio de CD (16 bit/44.1 kHz) tal cual a 44.1 kHz: aprox. 2%. Convirtiéndolo a 48 kHz para la salida: aprox. 4%.
• Conversión de 24 bit/96 kHz a 48 kHz: aprox. 5%. A 44.1 kHz: aprox. 7%.
• Conversión de 24 bit/192 kHz a 44.1 kHz: de aprox. 10% (solo el cálculo) a aprox. 15% (estimación aproximada de la carga total de reproducción, escalada a la frecuencia de reloj máxima).
• Envío de 24 bit/192 kHz a un DAC USB sin conversión: aprox. 20% (medido durante la reproducción real, con la pantalla encendida, incluido el hilo de transferencia).

Las cifras del motor desde “audio de CD” hasta “24 bit/192 kHz” proceden de ejecutar los mismos cálculos a toda velocidad a frecuencia de reloj máxima y convertirlos a un porcentaje del tiempo real. Durante la reproducción real el móvil baja su frecuencia de reloj a entre 200 MHz y 1 GHz, así que las cifras que muestra el móvil parecen entre 2 y 3 veces más altas (20–29% para 24 bit/192 kHz). La forma de escribir el código también marca una gran diferencia: la implementación actual en C y NEON tenía entre un tercio y un quinto de la carga de un prototipo anterior escrito en Java.

En la conversión de DSD a PCM, con ese móvil de 2012 y un DAC con batería, convertir DSD64 a PCM de 88.2 kHz y enviarlo por USB supuso aprox. un 11.8% para la conversión y aprox. un 5.8% para la transferencia USB (a aprox. 1 GHz). Cuando DSD64 se reprodujo por la salida integrada (48 kHz) en un móvil con Android 4.4, el hilo de decodificación usó un 23.8%, pero el móvil mantuvo su reloj en el mínimo de 300 MHz, así que escalar simplemente por la relación de frecuencias da aprox. un 3% a frecuencia de reloj máxima.

En los móviles que probamos, la carga con la pantalla encendida dependía más de la resolución de la pantalla que de la velocidad de la CPU (Android 4.x parece redibujar toda la pantalla incluso en actualizaciones pequeñas). Un móvil de 1080 × 1920 usó aprox. un 4% en la pantalla del reproductor, y uno de 1440 × 3120 con Android 11 usó aprox. un 8.5% (respecto a uno de sus 8 núcleos; aprox. un 1% del móvil entero). Los móviles antiguos tienen pantallas pequeñas y los de alta resolución tienen más potencia de proceso, así que por ahora la frecuencia de redibujado es la misma en todos los móviles.