Convolu¸c˜ao

A curva do tempo da fun¸c˜ao de kernel que realiza a convolu¸c˜ao dos dois sinais de entrada, observado na Figura 4.7, parece esbo¸car a complexidade computacional quadr´atica do algoritmo de convolu¸c˜ao. Este resultado ´e esperado uma vez que, para blocos grandes, o argumento de considerar o n´umero de processadores como uma constante que depende da placa utilizada, apresentado acima para a FFT, vale para qualquer outro algoritmo. ´E interessante ver que o tempo de processamento ´e reduzido para cerca de metade na GTX470, em rela¸c˜ao `as outras duas placas, o que se justifica exatamente pelo n´umero de processadores presente nesta placa (pouco menos de duas vezes a quantidade presente nas outras duas), o que ´e talvez o fator mais significativo na caracteriza¸c˜ao da tal constante que varia de placa para placa.

4.3.4 Phase Vocoder

Em rela¸c˜ao `a implementa¸c˜ao do Phase Vocoder, como observado na ´ultima se¸c˜ao, foi poss´ıvel determinar que a parte que consome o maior tempo da GPU ´e a parte do c´alculo dos valores dos osciladores na s´ıntese aditiva. Para se ter uma ideia de quantos recursos tal computa¸c˜ao consome, foram comparadas 5 implementa¸c˜oes distintas do c´alculo dos osciladores, descritas no in´ıcio desta se¸c˜ao. Trˆes delas utilizam consulta a uma tabela de 1024 pontos contendo um per´ıodo completo de um sinal senoidal, e duas delas utilizam fun¸c˜oes embutidas na GPU para ajudar nos c´alculos.

Nas Figuras 4.8 e 4.9 tamb´em est˜ao desenhados o per´ıodo do ciclo DSP para cada tamanho de bloco, e os resultados de tempo para uma implementa¸c˜ao de “controle” para funcionar como uma base de compara¸c˜ao. Esta implementa¸c˜ao de controle cont´em toda a parte de an´alise do Phase Vocoder (que cont´em por sua vez uma chamada da fun¸c˜ao de kernel que executa a FFT para estima¸c˜ao da fase e amplitude dos osciladores) e tamb´em o la¸co principal da s´ıntese, mas sem o c´alculo dos valores dos osciladores (o la¸co apenas soma um n´umero constante em cada rodada).

Em rela¸c˜ao `as implementa¸c˜oes (1), (2) e (3), ´e poss´ıvel ver que se comportam da forma espe- rada, ou seja, o tempo de c´alculo cresce proporcionalmente de acordo com o n´umero de opera¸c˜oes envolvidas: consulta truncada `a tabela ´e mais r´apida que consulta com interpola¸c˜ao linear, que por sua vez ´e mais r´apida que consulta com interpola¸c˜ao c´ubica. Consistentemente, todas elas s˜ao mais r´apidas na placa GTX 470, seguidas por um comportamento parecido nas placas GTX 275 e GF 100 GL.

A implementa¸c˜ao (4), que utiliza a fun¸c˜ao seno da API, toma aproximadamente o mesmo tempo que a implementa¸c˜ao (2) na placa GTX 275, mas tem um desempenho pior nas placas GTX 470 e GF 100 GL, atingindo nestas um resultado intermedi´ario entre as implementa¸c˜oes (1) e (2) at´e blocos de tamanho 214, e piorando consideravelmente para o bloco de tamanho 217.

Em rela¸c˜ao `a implementa¸c˜ao (5), que utiliza leitura interpolada de texturas, seu comportamento ´e um pouco dif´ıcil de explicar. Na placa GTX 275, possui o pior desempenho de todos os m´etodos, tomando cerca de 40% mais tempo do que a implementa¸c˜ao com interpola¸c˜ao c´ubica, a segunda mais cara. Por outro lado, nas placas GTX 470 e GF 100 GL, a implementa¸c˜ao (5) possui um desempenho compar´avel com todos os outros, sendo inclusive mais r´apida do que a implementa¸c˜ao de interpola¸c˜ao c´ubica. Pode-se supor que este comportamento deve ter algo a ver com diferen¸cas

na implementa¸c˜ao (em hardware) da leitura da mem´oria de texturas nos diferentes modelos de placa.

Destes gr´aficos pode-se ver que, para os modelos GTX 275 e GF 100 GL, blocos de tamanho maior ou igual a 216_{demoram mais tempo para serem computados do que o tempo dispon´ıvel para} aplica¸c˜oes em tempo real, independente da implementa¸c˜ao utilizada. Um resultado similar pode ser visto no modelo GTX 470, para blocos com 217 amostras.

Tamb´em pode-se observar que os tempos do Phase Vocoder crescem superlinearmente para todas as implementa¸c˜oes. Uma vez que o n´umero de osciladores na s´ıntese aditiva corresponde a cerca da metade do n´umero de amostras de um bloco, uma complexidade computacional quadr´atica ´e esperada. O grau de paralelismo trazido pela GPU n˜ao ´e suficiente para produzir diferen¸cas nos perfis dos v´arios m´etodos de consulta a tabela implementados, e diferen¸cas em escala s˜ao explicadas pela constante oculta na nota¸c˜ao O.

Dados os resultados apresentados, ´e poss´ıvel concluir que pequenas diferen¸cas de implementa¸c˜ao podem ter resultados significativos no tempo de execu¸c˜ao de um kernel na GPU. N˜ao est´a claro, por exemplo, o quanto a qualidade num´erica da fun¸c˜ao seno built-in ´e melhor do que a da interpola¸c˜ao c´ubica de 4 pontos, mas est´a claro que escolhas conscientes devem ser feitas para poder utilizar o potencial total da GPU para blocos grandes.

Tamb´em ´e poss´ıvel concluir que, se um ciclo DSP for restringido a poucas transferˆencias de mem´oria em cada dire¸c˜ao, ent˜ao n˜ao h´a a necessidade de se preocupar com o tempo de transferˆencia de mem´oria uma vez que sua magnitude ´e da ordem de d´ecimos de milissegundos, enquanto que os per´ıodos dos blocos DSP s˜ao da ordem de diversos milissegundos, mesmo para os menores tamanhos de bloco considerados.

Analisando os resultados de tempo da an´alise e s´ıntese do Phase Vocoder, ´e poss´ıvel obter o tamanho m´aximo dos blocos para os quais o uso de cada implementa¸c˜ao de oscilador ´e vi´avel, para cada modelo de placa considerado. O n´umero m´aximo de amostras atingido para cada cen´ario est´a resumido na tabela a seguir:

modelo \ implementa¸c˜ao 1 2 3 4 5 GTX 275 214 215 215 215 214 GTX 470 215 216 216 215 215 GF 100 GL 214 ₂14 ₂15 ₂14 ₂15

Cap´ıtulo 5

Processamento de ´audio em tempo

real em Android

Nos cap´ıtulos anteriores, bastante ˆenfase foi dada ao hardware utilizado e a programa¸c˜ao em cada ambiente foi utilizada como ferramenta para viabilizar a utiliza¸c˜ao de cada placa. No caso do Arduino, apesar de haver modelos com diferentes implementa¸c˜oes em hardware, o objetivo foi olhar para o microcontrolador como uma unidade de processamento de ´audio em tempo real e descobrir seus pontos fortes e fracos para esta tarefa. No caso da GPU, a discuss˜ao sobre processamento de prop´osito geral forneceu insumo `a abordagem, mas a implementa¸c˜ao foi executada em diferentes modelos de placa de uma fabricante espec´ıfica. Este cap´ıtulo, por sua vez, descreve a abordagem do sistema operacional Android para processamento de ´audio em tempo real. Como um dos grandes objetivos do sistema Android ´e ser execut´avel num conjunto muito grande de dispositivos, o foco se volta para o software.

Na Se¸c˜ao 5.1, a programa¸c˜ao para o sistema operacional Android ser´a descrita em linhas gerais. Na Se¸c˜ao 5.2, as possibilidades de entrada e sa´ıda de ´audio e de agendamento de execu¸c˜ao ser˜ao descritas, com objetivo de montar uma infraestrutura m´ınima para viabilizar o processamento de ´

audio em tempo real. Esta infraestrutura permitiu o desenvolvimento de um aplicativo que foi executado em diversos aparelhos e colheu dados sobre o desempenho de diferentes algoritmos de processamento de ´audio em tempo real. Estes algoritmos e os resultados ser˜ao discutidos na Se¸c˜ao 5.3.

5.1

Programa¸c˜ao para Android

O desenvolvimento de aplica¸c˜oes para o sistema Android ´e relativamente simples, pois utiliza uma API em Java bem definida, conven¸c˜oes simples e bem documentadas para descri¸c˜ao dos recursos utilizados, al´em de poder ser realizado a partir da ferramenta Eclipse, uma IDE para Java com licen¸ca livre. Esta se¸c˜ao descreve o esquema geral de programa¸c˜ao para Android e o arcabou¸co de desenvolvimento utilizado.