Notas técnicas

O reTONE muda o quanto processa conforme o formato da faixa, a versão do Android e a saída. Em faixas PCM, a conversão de taxa de amostragem acontece no máximo uma vez nos caminhos que o reTONE controla (internamente, uma conversão pode usar vários estágios de filtro) (no DSD, no máximo uma vez depois da etapa de DSD para PCM). Com Bluetooth, o celular e o codec Bluetooth processam o áudio mais uma vez depois disso. A reprodução é construída sobre o MediaPlayer e o AudioTrack do Android, e o engine do reTONE (escrito em C) cuida da decodificação e da conversão antes deles.

Android 4.x: Muitos celulares com Android 4.x abrem a thread de saída de música em uma taxa fixa, como 48 kHz, e faixas em outra taxa, como 44.1 kHz ou 96 kHz, são reamostradas dentro do mixer do Android antes de tocar. Os apps não têm como impedir essa conversão. O decodificador padrão do 4.x também pode reduzir FLAC de 24 bits para 16 bits ou falhar ao abrir FLAC de 192 kHz. Por isso, no 4.x, o engine do reTONE lê todos os FLAC e WAV, além de DSF, DFF e AIFF, converte uma única vez para a taxa de saída do celular (o valor de AudioTrack.getNativeOutputSampleRate) e entrega o áudio em 16 bits. O mixer do Android aceita áudio de 16 bits na mesma taxa como está, então nenhuma conversão de taxa de amostragem acontece do lado do Android. Ao reduzir para 16 bits, valores que 16 bits representam exatamente (como áudio de CD passado sem conversão) são entregues sem alteração; nos demais casos, o reTONE aplica dither TPDF e, quando a saída é de 44.1 kHz ou 48 kHz, usa noise shaping com realimentação de erro (o filtro de 5 coeficientes com ponderação E de Lipshitz, Vanderkooy e Wannamaker) para deslocar o ruído de quantização para frequências menos audíveis. Se ocorrer clipping, o erro realimentado é limitado a ±4 LSB para evitar oscilação. Os coeficientes foram projetados para 44.1 kHz e também são usados em 48 kHz. A quantidade total de ruído aumenta, mas ele é deslocado para as altas frequências, onde o ouvido é menos sensível. Porém, se você definir o volume do Android abaixo do máximo, o mixer do Android arredonda para 16 bits novamente depois de aplicar o volume, o que reduz o benefício do noise shaping. Isso não vale para celulares que ajustam o volume em hardware. Em qualquer caso, não há conversão de taxa de amostragem. MP3, AAC e formatos semelhantes tocam pelo caminho padrão do Android, mesmo no 4.x.

Android 5 ou posterior (caminhos que passam pelo mixer): No Android 10 ou posterior, os caminhos que não usam saída direta também se enquadram aqui. O mixer do Android dessa geração aceita float, então o engine do reTONE entrega áudio float ao AudioTrack, sem dither. Em celulares com saída de 16 bits, o Android então arredonda para 16 bits (o Android não aplica dither nesse ponto). Faixas FLAC, WAV e ALAC cuja taxa de amostragem difere da taxa de saída do celular seriam reamostradas pelo mixer do Android se fossem entregues como estão, e faixas acima de 16 bits seriam truncadas para 16 bits. O reamostrador padrão do AOSP usa qualidade dinâmica média (DYN_MED) quando a configuração de qualidade (af.resampler.quality) não está definida e cai para uma qualidade ainda menor quando a carga estimada dos reamostradores em uso ao mesmo tempo excede um limite. No celular que verificamos, essa configuração não estava definida. O engine do reTONE reamostra apenas as faixas que atendem a essas condições, e você pode desativar isso na configuração “Conversion by reTONE”. Faixas de 16 bits na taxa de saída do celular (como áudio de CD em um celular de 44.1 kHz) não precisam de conversão, então tocam pelo caminho padrão do Android.

Saída direta (Android 10 ou posterior; a disponibilidade depende do celular): A disponibilidade da “saída direta”, que envia o áudio na taxa da faixa sem passar pelo mixer, e do “offload”, que decodifica áudio comprimido no chip, depende do celular e da saída. No Android 10 ou posterior, um app pode perguntar ao celular, com AudioTrack.isDirectPlaybackSupported, se um determinado formato, taxa e profundidade de bits podem ser enviados diretamente para a saída atual. O reTONE usa esse caminho apenas quando o celular responde que sim e a política de áudio do celular realmente encaminha PCM para a saída direta; caso contrário, toca pelo caminho padrão do Android. A resposta varia conforme a saída, então o reTONE pergunta de novo sempre que fones ou USB são conectados ou desconectados. Em celulares cuja política de áudio encaminha PCM para a saída direta, os principais formatos que não podiam ser enviados diretamente eram PCM de 16 bits a 44.1, 48 e 88.2 kHz (o áudio de CD cai nesse grupo). 24 bits e float podiam ser enviados diretamente na taxa da faixa, e MP3 e AAC (faixas de 60 segundos ou mais) iam para o offload. Por isso, o reTONE decodifica áudio lossless de 16 bits (FLAC, ALAC, WAV) para PCM (ALAC com o decodificador próprio do reTONE, se o celular não tiver um) e o entrega ao MediaPlayer por meio do MediaDataSource como um WAV de 24 bits com os 8 bits inferiores preenchidos com zeros. Os 16 bits superiores permanecem inalterados. Antes de trocar, ele decodifica de fato o primeiro bloco para confirmar que sai PCM real de 16 bits e, se não conseguir confirmar, volta ao caminho padrão. Áudio lossless de 24 bits e de taxa alta, além de MP3 e AAC, já vão para a saída direta ou para o offload, então são entregues como estão. Os apps não têm como ler qual saída o celular realmente usou, então “DIRECT” na tela do player é uma expectativa. O reTONE costumava se basear apenas na resposta do celular, mas o Android padrão ainda pode enviar PCM ao mixer mesmo quando responde que sim, e alguns celulares mostravam DIRECT quando o áudio não era realmente direto. Desde a versão 0.92.48, o reTONE também verifica a política de áudio do celular. Desde a 0.90.1, “DIRECT” aparece apenas para faixas lossless, e nunca por Bluetooth. Com offload, também não dá para verificar se a taxa de amostragem muda dentro do chip. Nesse caminho, os efeitos sonoros do lado do Android não são aplicados (em alguns celulares, os efeitos rodam dentro do chip), enquanto as configurações de hardware do DAC (como filtros) continuam valendo. Pode ser ativado ou desativado em Settings.

Saída direta para DACs USB: Quando você conecta um DAC USB a um celular com suporte a host USB (OTG), o reTONE envia os dados direto ao DAC, sem passar pelo caminho de áudio do Android. No celular que verificamos, o caminho padrão do Android convertia o áudio para 16 bits/48 kHz para o DAC USB (uma saída de 32 bits/192 kHz também estava aberta, mas não era usada para música). A saída direta do reTONE funciona assim.

• Usando a API de host USB do celular, o reTONE encontra o DAC, obtém a sua permissão e lê os descritores USB (no USB Audio Class 2.0: o ID do clock, as configurações alternativas da interface de reprodução, o endpoint de saída e o endpoint de feedback; no Class 1.0: as taxas de amostragem e o tamanho de pacote de cada configuração alternativa).
• Ele assume o controle do DAC no lugar do driver do Android (claimInterface) e prefere uma configuração alternativa PCM, de 2 canais e 32 bits (24 ou 16 bits se não houver).
• Ele lê as taxas de amostragem aceitas com o GET RANGE da fonte de clock. Se a taxa da faixa estiver no intervalo, ele a define com SET CUR e a confirma com GET CUR. Apenas faixas em taxas não aceitas, ou em taxas que o USB do celular se recusa a transportar (a partir da 0.92.68), são reamostradas, uma vez, pelo reTONE para uma taxa que o DAC aceita. Faixas em taxas que o DAC aceita não passam por conversão de taxa nem por dither. Faixas de até 24 bits são enviadas com os dados originais colocados sem alteração nos bits superiores de uma palavra de 32 bits (ao usar o volume do DAC ou ao ajustar o volume no próprio DAC). Faixas de inteiros de 32 bits também seguem um caminho que as mantém como inteiros (a partir da 0.92.65). Apenas valores que a profundidade de bits do DAC não consegue representar exatamente são arredondados, com dither TPDF quando o DAC é de 24 bits ou menos.
• As transferências são tratadas no lado C, com transferências isócronas do usbdevfs. Em DACs High Speed que recebem áudio a cada 0.125 ms (a maioria), 1 ms de áudio (8 microframes) é agrupado em uma transferência, e 64 delas ficam enfileiradas com antecedência. Em DACs com intervalo maior, cada transferência contém 32 pacotes e menos são enfileiradas, mantendo cerca de 64 ms de antecedência. DACs assíncronos informam, pelo endpoint de feedback, o número de frames por microframe, e o reTONE ajusta a quantidade enviada de acordo. O formato desse valor varia conforme o DAC, então o reTONE o detecta a partir do que chega. Quando o reTONE aplica o volume, faz isso logo antes do envio, então as mudanças têm efeito imediato (cada mudança é suavizada ao longo de cerca de 5 ms para evitar saltos bruscos).
• Nesse período, MP3, AAC e formatos semelhantes também são decodificados para PCM com o decodificador do celular (MediaCodec) antes do envio, de modo que o reTONE reproduz todas as faixas. Desconectar o DAC pausa a reprodução. Quando outro app começa a tocar, o reTONE pausa e devolve o DAC ao Android, e o retoma quando você volta a tocar no reTONE. Se o DAC não for devolvido ao Android, por exemplo após uma parada forçada, o reTONE o devolve logo depois de uma atualização e quando você abre o reTONE com “USB DAC direct output” desativado.

Muitos celulares da geração Android 4.1 não conseguem usar um DAC USB como saída de áudio, mas a saída direta do reTONE usa apenas a função de host USB, então ainda consegue enviar o áudio. Com o nosso celular de teste de 2012 (Android 4.1) e um DAC com bateria, 24 bits/192 kHz tocaram sem conversão. Testamos pessoalmente DACs USB Audio Class 2.0. DACs Class 1.0 também são compatíveis, mas os testes na prática até agora vêm apenas de relatos de usuários. Celulares mais antigos só conseguem fornecer uma corrente pequena por USB, então DACs alimentados pelo barramento podem não ser reconhecidos. Também vimos um caso em que a interferência de rádio do Wi-Fi chegou ao DAC pelo cabo USB e causou ruídos intermitentes. A reprodução não precisa de conexão, então recomendamos ativar o modo avião ao ouvir por um DAC USB.

A conversão de taxa de amostragem recalcula a forma de onda entre as amostras originais, então a qualidade do filtro aparece diretamente no som. O filtro do reTONE é um filtro FIR feito aplicando uma janela de Kaiser a uma função sinc. Ele usa uma estrutura polifásica, que divide os coeficientes em grupos conforme a razão de conversão e calcula só o necessário. O projeto se apoia em dois critérios: não reduzir nenhum som audível e manter bem suprimido o aliasing causado pela conversão.

• Banda de passagem: plana até 20 kHz (dentro de ±0.001 dB por projeto; para conversões entre taxas de 44.1 kHz ou mais).
• Banda de rejeição: começa em “a taxa menor − 20 kHz”. Entre 44.1 kHz e 48 kHz, isso dá 24.1 kHz. O aliasing que cai nessa faixa aparece acima de 20 kHz e fica fora da banda audível (até 20 kHz).
• Atenuação (meta de projeto): 120 dB para celulares com saída em float (Android 5 ou posterior), 100 dB para celulares com saída de 16 bits (Android 4.x). O comprimento do filtro e a janela são projetados com uma margem de 2 dB sobre a meta, para que o valor calculado supere a meta em todas as conversões (para 44.1 → 48 kHz, os valores calculados são cerca de 122 dB e cerca de 102 dB). O aliasing residual em −100 dB fica bem abaixo do piso de ruído de 16 bits (por volta de −93 dBFS em toda a banda, incluindo o dither), então 100 dB de atenuação não se distinguem de 120 dB ao ouvido.
• Taps: definidos a partir da atenuação e da banda de transição pela fórmula da janela de Kaiser (86 taps para 44.1 ↔ 48 kHz a 120 dB).
• Estágios 2:1: os estágios que reduzem a taxa exatamente pela metade, como 96 → 48 kHz, usam um filtro de meia banda (half-band), em que metade dos coeficientes é zero e o restante é simétrico, o que reduz as multiplicações a cerca de um quarto de um filtro comum. 192 → 48 kHz usa dois estágios de meia banda, e as razões restantes, como 88.2 → 48 kHz, ficam a cargo de um filtro polifásico.

Nas medições, sinais de 1 kHz, 19 kHz e 19.9 kHz saíram no mesmo nível, com diferença de até 0.01 dB. Com uma entrada de 30 kHz, o aliasing que aparece entre 0 e 20 kHz ficou pelo menos 104.6 dB abaixo do sinal original na saída a 44.1 kHz e 48 kHz, e pelo menos 116 dB abaixo na conversão a partir de 192 kHz (medido antes do arredondamento para 16 bits). São valores em uma única frequência. Por projeto, toda a banda de rejeição é suprimida a pelo menos as metas de atenuação acima.

Como a conversão cria novos pontos entre as amostras originais, faixas altas podem acabar com pontos acima de 0 dBFS. Quando convertemos para 48 kHz várias gravações comerciais que tínhamos, os pontos acima de 0 dBFS representaram 0.0001–0.001% do total, com máximos de +0.38 a +0.59 dB. Eles sofrem clipping na saída de 16 bits ou no mixer do celular, então, ao reamostrar, e somente nesse caso, o reTONE reduz o nível em 1 dB, deixando margem acima do máximo medido. Faixas que não são reamostradas ficam inalteradas, então, no mesmo celular, as faixas reamostradas ficam 1 dB mais baixas. Ao passar sem pausa para a faixa seguinte, o estado do reamostrador é transferido, de modo que o início e o fim das faixas não são cortados pelo processamento (a partir da 0.92.57).

O volume não é aplicado dentro do motor do reTONE. Ele é aplicado no mixer do Android (o volume do AudioTrack). Se fosse aplicado dentro do motor, as mudanças só chegariam depois de terminar de tocar os cerca de 500 ms de áudio guardados no buffer do AudioTrack, e os botões de volume pareceriam lentos. Em celulares com saída de 16 bits, abaixar o volume faz o Android arredondar de novo para 16 bits (o Android não aplica dither nesse ponto).

Os cálculos são escritos em C e usam instruções ARM NEON para processar os canais esquerdo e direito juntos. O laço interno do filtro lê os coeficientes como vetores e usa quatro acumuladores para esconder a latência. O dither, incluindo números aleatórios, arredondamento, clipping e realimentação de erro, também é feito inteiramente em NEON, evitando transferências entre o NEON e os registradores de uso geral, que são lentas em núcleos mais antigos (Cortex-A9). As versões para Intel (x86) usam um caminho em C puro, sem NEON. Os números de carga abaixo vêm dos celulares ARM que testamos.

Há três lugares para reduzir o volume: ① dentro do reTONE, aplicado aos dados (digital), ② o volume digital interno do DAC, controlado por USB, e ③ o botão ou os botões no próprio DAC. Qual é usado depende do método de ajuste que você escolhe ao conectar o DAC pela primeira vez e de o DAC permitir ou não controlar o volume por USB.

② Volume via USB: o USB Audio Class tem um mecanismo de volume chamado Feature Unit, e o GET RANGE lê o mínimo, o máximo e o tamanho do passo (em unidades de 1/256 dB). O reTONE converte o seu volume (um único ganho que combina os passos do Android e o volume fino) em dB. Se o valor estiver dentro dessa faixa, o reTONE o envia ao DAC e mantém a própria saída no máximo. Só quando o volume fica abaixo da faixa é que a diferença é aplicada ao PCM com ①. 0 é mudo.

① Dentro do reTONE: Para DACs sem volume por Feature Unit e para DACs configurados como “reTONE adjusts”, o reTONE aplica o volume aos dados antes de enviá-los, suavizando cada mudança ao longo de cerca de 5 ms. Ele é aplicado logo antes do envio, então as teclas de volume respondem imediatamente.

③ O próprio DAC: Não é possível ler por USB se o DAC tem controle de volume próprio. Por isso, na primeira vez que você conecta um DAC, o reTONE pergunta uma vez como o volume do DAC deve ser ajustado, com três opções: “On the DAC itself”, “Volume keys (DAC adjusts)” e “Volume keys (reTONE adjusts)”. Alguns DACs informam que aceitaram um comando de volume sem de fato alterá-lo; para esses, escolher “reTONE adjusts” fixa o volume do DAC no máximo e o reduz com o ①. Se você escolher “On the DAC”, tanto o ② quanto o ① ficam fixos no máximo, e pressionar as teclas de volume não muda nada (uma mensagem avisa isso). Em DACs com controle de volume analógico, evitar a atenuação digital permite aproveitar ao máximo o DAC. A escolha é lembrada para cada modelo de DAC (ID do fornecedor e ID do produto USB) e pode ser alterada na configuração “DAC volume”.

Quando “On the DAC” é escolhido, ou quando o volume do DAC é usado (dentro da faixa de volume do DAC), faixas em taxas que o DAC aceita são enviadas sem alterar os dados. Somente quando você define o volume abaixo da faixa do DAC o reTONE aplica o restante. Nesse caso, se a faixa for lossless (incluindo DSD nativo) e sua profundidade de bits couber na do DAC, a tela do caminho do sinal mostra BIT-PERFECT (faixas de inteiros de 32 bits apenas quando seguem o caminho de inteiros). O que acontece dentro do DAC não pode ser verificado.

Faixas DSF e DFF são enviadas como DSD, sem conversão para PCM, apenas quando o DAC aceita DSD nativo e seu volume pode ser controlado por USB (e o DAC não está definido como “reTONE adjusts”). O reTONE não consegue alterar o volume do próprio DSD, então o controle de volume do lado do DAC é necessário. A tela do player mostra algo como “DSD64 → USB AUDIO • DSD64 DIRECT”.

O envio funciona assim.

• O DSD nativo funciona com DACs cujos descritores USB incluem uma configuração alternativa para dados brutos (TYPE I RAW DATA).
• Os bits do DSD são empacotados de 4 em 4 bytes em uma palavra de 32 bits por canal, com o bit mais antigo no topo. O DSF armazena os bits com o LSB primeiro, então a ordem dos bits em cada byte é invertida antes do empacotamento. As palavras são enviadas em big-endian (a mesma hipótese do DSD_U32_BE do Linux). Esse reempacotamento é feito em C, e o buffer circular de transferência guarda cerca de 500 ms.
• O clock do DAC é ajustado para “taxa do DSD ÷ 32” (88.2 kHz para DSD64, 176.4 kHz para DSD128).
• Silêncio, pausas e finais de faixa são preenchidos com o padrão de silêncio do DSD, 0x69.

Essa ordem de bytes e de bits foi verificada pela reprodução correta no DAC que testamos. Ainda não foi verificada com outros DACs, e DoP (DSD over PCM) não é suportado. DFF com compressão DST também não pode ser lido.

Envio de DSD (configuração): “Sending DSD” aparece em “Sound” nas configurações somente enquanto um DAC que pode usar DSD nativo estiver conectado. O padrão é “Send as DSD” (o DAC toca o DSD diretamente), e você pode mudar para “Convert to PCM” (o reTONE converte para PCM). Se as faixas DSD falharem, ou se preferir a reprodução em PCM, escolha converter para PCM. A escolha fica guardada para cada modelo de DAC, e ao mudar a faixa atual é reaberta na mesma posição. Encontramos um DAC que falhava por instantes com gravações DSD cuja modulação passava do nível de referência de 50%. A transferência estava normal, então isso parece se dever ao projeto do DAC. Converter para PCM evita as falhas nesse caso também.

Conversão DSD → PCM: quando o DSD nativo não é usado (com DACs que não atendem às condições, quando “Convert to PCM” é escolhido, e na saída para Bluetooth, fones ou alto-falante), o reTONE converte o DSD para PCM em dois estágios.

• Estágio 1: o fluxo de bits DSD é decimado por um fator de 32, 64 e assim por diante, gerando PCM a cerca de 88.2 kHz ou mais (DSD64 por 32 para 88.2 kHz, DSD128 por 64 para 88.2 kHz). O filtro é um FIR com janela de Kaiser. A banda passante vai até o maior valor entre 20 kHz e um quarto da taxa de saída, a banda de rejeição começa em “taxa de saída − banda passante”, e a atenuação é de 100 dB para saída de 16 bits e de 110 dB para float e USB. O número de taps é definido pela fórmula da janela de Kaiser. O cálculo usa consultas a tabelas de 16 bits, e as tabelas são montadas uma vez por configuração e reutilizadas. Nas medições, a resposta em 20 kHz foi de 0.000 dB, e o aliasing abaixo de 20 kHz ficou em −101 dB (projeto de 100 dB) / de −110 a −117 dB (projeto de 110 dB).
• Estágio 2: se necessário, o mesmo reamostrador descrito na seção de filtros converte uma única vez para a taxa de saída do celular (como 44.1 kHz ou 48 kHz na saída interna).
• Nível: convertido de modo que o 0 dB do SACD (modulação de 50%) vire −6 dBFS (uma convenção comum; a partir da 0.69.0. As versões anteriores usavam −12 dBFS e tocavam 6 dB mais baixo).

Ao enviar PCM para um DAC USB, o reTONE envia PCM a “taxa do DSD ÷ 32” (88.2 kHz para DSD64, 176.4 kHz para DSD128, 352.8 kHz para DSD256) assim mesmo, sem a conversão do estágio 2, se o DAC suportar. Como o DSD é convertido para PCM, DIRECT não aparece nesse caso.

O reTONE busca “não fazer nada quando está parado” e “não desenhar nada ao tocar com a tela desligada”. As tarefas periódicas só rodam durante a reprodução: a cada segundo com a tela ligada e a cada 5 segundos com ela desligada, e a barra de busca da tela do player redesenha só a si mesma a cada 250 ms. O relógio e a bateria são atualizados por notificações do sistema, sem consultas periódicas.

Uso de CPU do reTONE em relação a um núcleo, no nosso celular de teste de 2012 (Android 4.1, Cortex-A9 de 2 núcleos).

• Parado: 0%.
• Tocando com a tela desligada: o desenho para. As faixas tocadas pela reprodução padrão do Android usam quase 0%, enquanto as tocadas pelo motor do reTONE (FLAC, WAV e outras no Android 4.x) somam a carga de decodificação e conversão abaixo.
• Tocando com a tela do player à vista: cerca de 2% (medido durante a reprodução real; quase tudo é o redesenho da barra de busca, sem incluir a decodificação).
• Motor do reTONE enviando áudio de CD (16 bits/44.1 kHz) sem alteração a 44.1 kHz: cerca de 2%. Convertendo para 48 kHz na saída: cerca de 4%.
• Conversão de 24 bits/96 kHz para 48 kHz: cerca de 5%. Para 44.1 kHz: cerca de 7%.
• Conversão de 24 bits/192 kHz para 44.1 kHz: de cerca de 10% (só o cálculo) a cerca de 15% (estimativa aproximada da carga total da reprodução, ajustada ao clock máximo).
• Envio de 24 bits/192 kHz para um DAC USB sem conversão: cerca de 20% (medido durante a reprodução real, com a tela ligada, incluindo a thread de transferência).

Os valores do motor, de “áudio de CD” a “24 bits/192 kHz”, vêm da execução dos mesmos cálculos em velocidade total no clock máximo, convertidos em porcentagem do tempo real. Durante a reprodução real, o celular reduz o clock para algo entre 200 MHz e 1 GHz, então os valores mostrados no celular parecem 2 a 3 vezes maiores (20–29% para 24 bits/192 kHz). A forma como o código é escrito também faz muita diferença: a implementação atual em C e NEON tem entre um terço e um quinto da carga de um protótipo anterior escrito em Java.

Na conversão de DSD para PCM, com aquele celular de 2012 e um DAC com bateria, converter DSD64 para PCM a 88.2 kHz e enviá-lo via USB levou cerca de 11.8% na conversão e cerca de 5.8% na transferência USB (a cerca de 1 GHz). Quando o DSD64 tocou pela saída interna (48 kHz) em um celular com Android 4.4, a thread de decodificação usou 23.8%, mas o celular manteve o clock no mínimo de 300 MHz; ajustando simplesmente pela razão de clock, isso dá cerca de 3% no clock máximo.

Nos celulares que testamos, a carga com a tela ligada dependeu mais da resolução da tela do que da velocidade da CPU (o Android 4.x parece redesenhar a tela inteira mesmo em pequenas atualizações). Um celular de 1080 × 1920 usou cerca de 4% na tela do player, e um de 1440 × 3120 com Android 11 usou cerca de 8.5% (em relação a um dos seus 8 núcleos; cerca de 1% do celular inteiro). Celulares antigos têm telas pequenas e celulares de alta resolução têm mais poder de processamento, então, por enquanto, a frequência de redesenho é a mesma em todos os celulares.