Medi¸c˜ao de tempo de diferentes algoritmos

A cada ciclo DSP, um m´etodo agendado ´e executado e processa o bloco atual de amostras do sinal de ´audio. Este m´etodo inclui a execu¸c˜ao de rotinas para medi¸c˜ao de tempo, convers˜ao entre a representa¸c˜ao em shorts e doubles (ida e volta), execu¸c˜ao do m´etodo perform() do algoritmo DSP e escrita das amostras para o buffer de sa´ıda. Para os prop´ositos desta investiga¸c˜ao, chamamos o tempo utilizado para realizar este conjunto de opera¸c˜oes de tempo de callback. O tempo de callback ´e, ent˜ao, o tempo necess´ario por um conjunto minimal de opera¸c˜oes DSP para executar qualquer algoritmo desejado, e assim pode ser comparado com o per´ıodo te´orico do ciclo DSP para determinar a viabilidade de certas opera¸c˜oes.

Se o tempo do callback DSP eventualmente exceder o per´ıodo te´orico do ciclo DSP, ent˜ao o sis- tema n˜ao consegue gerar amostras em tempo real, ou seja, entregar o resultado da computa¸c˜ao para reprodu¸c˜ao antes que o ciclo DSP termine. Como em dispositivos m´oveis h´a, em geral, restri¸c˜oes significativas com rela¸c˜ao ao poder computacional, a primeira quest˜ao que surge ´e se o modelo de processamento desenvolvido para este trabalho, que ´e baseado em Java, inclui c´odigo para registro de tempo, converte amostras de um tipo para outro, depende do agendamento presente na API do

5.3 RESULTADOS E DISCUSS ˜AO 89

Modelo Fabricante Modelo da CPU Frequˆencia da CPU RAM (MB) Vers˜ao (API)

GT-P1000L Samsung Cortex-A8 1 GHz 512 2.2 (8)

LG-P500h (1) LG ARM 11 600 MHz 512 2.3.3 (10)

LG-P500h (2) LG ARM 11 600 MHz 512 2.3.3 (10)

GT-I9000B Samsung Cortex A8 1 GHz 512 2.3.3 (10)

LG-P698f (1) LG ARMv6 800 MHz 512 2.3.4 (10)

LG-P698f (2) LG ARMv6 800 MHz 512 2.3.4 (10)

R800i Sony Ericsson Scorpion 1 GHz 512 2.3.4 (10)

GT-I8150B Samsung Scorpion 1.4 GHz 512 2.3.5 (10)

XT320 Motorola Qualcomm MSM7225A 600 MHz 512 2.3.6 (10)

GT-S5830i Samsung ARM 11 800 MHz 278 2.3.6 (10)

GT-S5360L Samsung ARMv6 830 MHz 290 2.3.6 (10)

GT-I8530 Samsung ARM Cortex-A9 Dual-core 1 GHz 768 2.3.6 (10)

A750 Lenovo ARM Cortex-A9 1 GHz 512 2.3.6 (10)

GT-S5360B Samsung ARMv6 830 MHz 290 2.3.6 (10)

MB860 Motorola ARM Cortex-A9 Dual-core 1 GHz 1024 2.3.6 (10)

Blade ZTE Qualcomm MSM7227 600 MHz 512 2.3.7 (10)

Transformer TF101 Asus Cortex-A9 Dual-core 1GHz 1024 4.0.3 (15)

NB0026 Multilaser ARMv7 1 GHz 512 4.0.4 (15)

GT-S7562 Samsung Cortex-A5 1 GHz 768 4.0.4 (15)

LG-P990 LG Cortex-A9 Dual-core 1 GHz 512 4.0.4 (15)

ST25a Sony Cortex-A9 Dual-core 1 GHz 512 4.0.4 (15)

MZ607 Motorola Cortex-A9 Dual-core 1.2 GHz 1000 4.0.4 (15)

Transformer TF101 Asus Cortex-A9 Dual-core 1 GHz 1024 4.1.1 (16)

MB526 Motorola Cortex-A8 1 GHz 512 4.1.2 (16)

GT-I8190L Samsung Cortex-A9 Dual-core 1 GHz 1000 4.1.2 (16)

LT26i Sony-Ericsson Qualcomm MSM8960 Dual-core 1.5 GHz 10224 4.1.2 (16)

GT-I9300 (1) Samsung Cortex-A9 Quad-core 1.4 GHz 1024 4.1.2 (16)

GT-I9300 (2) Samsung Cortex-A9 Quad-core 1.4 GHz 1024 4.1.2 (16)

GT-I9300 (3) Samsung Cortex-A9 Quad-core 1.4 GHz 1024 4.2.2 (17)

Nexus 7 (1) Asus Cortex-A9 Quad-core 1.2 GHz 1024 4.2 (17)

Nexus 7 (2) Asus Cortex-A9 Quad-core 1.2 GHz 1024 4.2.2 (17)

GT-I9000B Samsung Cortex-A8 1 GHz 512 4.2.2 (17)

MK16i Sony-Ericsson Qualcomm MSM8255 1 GHz 512 4.2.2 (17)

Galaxy Nexus 4 Samsung Cortex-A9 Dual-core 1.2 GHz 1024 4.3 (18)

Nexus 4 LG Cortex-A9 Quad-core 1.5 GHz 2048 4.3 (18)

Tabela 5.1: Tabela de dispositivos testados. Note que existem alguns modelos repetidos: dois LG-P500h (mesma vers˜ao da API), dois LG-P698f (mesma vers˜ao da API), trˆes GT-I9300 (dois com vers˜ao 4.1.2 e um com vers˜ao 4.2.2) e dois Nexus 7 (um com vers˜ao 4.2 e outro com vers˜ao 4.2.2).

Android, e opera com o mesmo n´ıvel de prioridade que outros aplicativos comuns, pode de fato ser utilizado em tempo real.

Para responder a esta quest˜ao, o primeiro passo foi executar 3 algoritmos simples e tirar a m´edia do per´ıodo de execu¸c˜ao dos callbacks DSP para diferentes tamanhos de bloco. Estes algoritmos s˜ao: • Loopback: um m´etodo perform() vazio, que retorna imediatamente sem alterar as amos- tras no buffer. Esta implementa¸c˜ao ´e utilizada para estabelecer o overhead intr´ınseco ao modelo apresentado na Se¸c˜ao 5.2.4

• Reverb: um filtro IIR de ordem 3 que emite o sinal gerado pela f´ormula y(n) = −gx(n) + x(n − m) + gy(n − m) (Oppenheim et al.,1999).

• FFT: Uma implementa¸c˜ao em Java do algoritmo da FFT. (Cooley e Tukey,1965;Sedgewick e Schidlowsky

,1998).

Com estas trˆes implementa¸c˜oes, ´e poss´ıvel ter uma ideia de como ´e realizar processamento de ´audio em tempo real em diferentes combina¸c˜oes de hardware e software rodando Android. Os resultados ser˜ao vistos a seguir.

An´alise de desempenho dos algoritmos

Nas Figuras 5.6, 5.7 e 5.8, ´e poss´ıvel ver os resultados dos algoritmos de, respectivamente, loopback, reverb e FFT, rodando em dispositivos distintos com diferentes vers˜oes da API. Em todas as figuras s˜ao apresentados somente os resultados para blocos grandes (de 512 at´e 8192 amostras) por serem consistentes com os resultados para blocos pequenos. Em todas as figuras tamb´em pode-se ver o per´ıodo te´orico do ciclo DSP, que corresponde ao tempo m´aximo que um m´etodo pode demorar para escrever novas amostras na fila do hardware de sa´ıda, sob as restri¸c˜oes de tempo real.

´

E interessante notar que o padr˜ao das curvas para o algoritmo loopback n˜ao parece condizer com a quantidade de computa¸c˜ao realizada por este algoritmo (ou seja, nenhuma) quando compa- rado com os algoritmos reverb e FFT. Para blocos de tamanho grande, o padr˜ao observado para os dois ´ultimos parece respeitar a quantidade de computa¸c˜ao realizada, enquanto que para alguns dis- positivos o algoritmo loopback apresenta maior tempo de execu¸c˜ao. Pode-se supor que este padr˜ao esteja relacionado a algum comportamento do escalonador de processos do sistema operacional, que talvez realize a aloca¸c˜ao de fra¸c˜oes de tempo da CPU de forma mais otimizada quando existe realmente computa¸c˜ao sendo executada.

Uma vez que loopback e reverb tomam tempo linear com respeito ao tamanho do bloco, os padr˜oes que ocorrem nos primeiros dois gr´aficos s˜ao esperados. Mesmo assim, estes gr´aficos s˜ao ´

uteis para hierarquizar os dispositivos com respeito a seu poder computacional, e tamb´em para fornecer uma avalia¸c˜ao precisa do tempo dispon´ıvel para computa¸c˜ao extra para cada dispositivo. A complexidade computacional da FFT explica a curva vista na Figura 5.8. Espera-se que, para blocos de tamanho grande, a FFT em tempo real se torne invi´avel para todos os dispositivos.

Em geral, o mecanismo de processamento em tempo real desenvolvido deixa bastante espa¸co para os algoritmos de processamento. O filtro reverberante ´e vi´avel para todos os dispositivos e tamanhos de bloco, e a FFT ´e vi´avel para uma parcela grande (com exce¸c˜ao de apenas 4 modelos com API vers˜ao 2 e apenas um modelo com API vers˜ao 4).

Em rela¸c˜ao `a diferen¸ca entre n´ıveis da API ´e poss´ıvel observar que, de modo geral, existem mais aparelhos com CPUs mais r´apidas e com m´ultiplos cores que rodam a vers˜ao 4.x do Android. Assim, o tempo menor de processamento nestes aparelhos em rela¸c˜ao `aqueles que rodam a vers˜ao 2.x ´e esperado.