LUIS HENRIQUE ALVES LOURENÇO PROCESSAMENTO PARALELO DE ÁUDIO EM GPU

Transcrição

1 LUIS HENRIQUE ALVES LOURENÇO PROCESSAMENTO PARALELO DE ÁUDIO EM GPU CURITIBA 2009

2 LUIS HENRIQUE ALVES LOURENÇO PROCESSAMENTO PARALELO DE ÁUDIO EM GPU Trabalho de Conclusão de Curso apresentado como requisito parcial à obtenção do grau de Bacharel em Ciência da Computação. Programa de Graduação, Setor de Ciências Exatas, Universidade Federal do Paraná. Orientador: Prof. Dr. Luis Carlos Erpen de Bona CURITIBA 2009

3 Sumário Lista de Figuras v Resumo vi 1 Introdução Programação Paralela Paralelismo em Nível de Instrução Multiprocessadores e Paralelismo em Nível de Thread Paralelismo em Nível de Dados Compute Unified Device Architecture (CUDA) Escondendo Processadores Gerenciamento de Threads Hierarquia de Memória Áudio Digital Processamento de Áudio Digital Compressão de Áudio O padrão MPEG-1 Layer III Banco de Filtros Polifásicos de Análise ii

4 iii Transformação Discreta de Cosseno Modificada Modelagem Psicoacústica Quantificação não-uniforme Codificação de Huffman Formatação da Seqüência de Bits LAME Ain t an Mp3 Encoder Processamento de Áudio em GPU Modelo de Servidor de Áudio Um Servidor de Áudio com codificação em GPU Detalhes da Implementação Codificação em GPU Resultados Conclusão Referências Bibliográficas Anexo A -- CUDA Application Programming Interface A.1 Extensões da Linguagem C A.1.1 Qualificadores de Função A.1.2 Qualificadores de Variáveis A.1.3 Parâmetros de Configuração da Execução A.1.4 Variáveis Pré-definidas A.1.5 O Compilador NVCC

5 iv A.2 Componente de Execução Comum A.2.1 Tipos Pré-definidos A.2.2 Funções Matemáticas A.2.3 Funções de Tempo A.2.4 Tipo Textura A.3 Componente de Execução em GPU A.3.1 Funções Matemáticas A.3.2 Função de Sincronização A.3.3 Funções de Textura A.3.4 Funções Atômicas A.4 Componente de Execução em CPU A.4.1 API de Execução A.4.2 API do Driver Anexo B -- Speaker (servidor) Anexo C -- Listener (cliente) Anexo D -- lhal04.h Anexo E -- psykernel

6 v Lista de Figuras Figura 2.1 Exemplo de Soma Paralela de um Vetor Figura 2.2 Modelo da Arquitetura NVidia (GeForce 8) [HALFHILL, 2008] Figura 2.3 Hierarquia de Memória em CUDA Figura 3.1 Processo de Codificação MP Figura 3.2 Limiar Absoluto de Audição Figura 3.3 Mascaramento de Freqüência Figura 3.4 Quantificação não-uniforme Figura 4.1 Modelo de Servidor de Áudio

7 Resumo Este trabalho se propõe a demonstrar que o processamento paralelo em Unidades de Processamento Gráfico (GPU, do inglês, Graphics Processing Unit) pode ser amplamente utilizado para o processamento de áudio a fim de melhorar o desempenho dos algoritmos existentes e permitir que mais dados sejam processados com menor latência. Com isso, pode permite-se uma melhora sensível na qualidade do conteúdo. Esse tipo de abordagem torna-se útil devido às novas tecnologias multimídia, como a TV digital de alta definição, os conteúdos online (Streamming de áudio e vídeo) e a comunicação através de meios digitais, como o VoIP ou videoconferência. Palavras-chave: Processamento Paralelo, GPU, CUDA, MPEG-1 Layer III, MP3, Servidor de Áudio. vi

8 1 1 Introdução A produção e o processamento de multimídia no formato digital estão se popularizando cada vez mais. Isso pode ser percebido na evolução da indústria do cinema e dos jogos, no desenvolvimento da tv digital, nos estúdios de gravação de música, na utilização dos meios digitais para comunicação, na popularização dos aparelhos celulares, reprodutores de vídeo e de música, entre outros [PEDDIE, 2001]. Um dos aspectos fundamentais para os sistemas multimídia é a baixa latência [LAGO, 2004], especialmente no caso de mídias contínuas como o áudio e o vídeo. Esses sistemas exigem baixa latência para um grande volume de dados. Uma abordagem que tem se mostrado eficiente para aplicações que necessitam de alta capacidade de processamento ou que processam um grande volume de dados é o processamento paralelo [HENNESSY; PATTERSON, 1990]. A exigência do mercado de processadores gráficos resultou na evolução das Unidades de Processamento Gráfico (GPU 1 ) em um dispositivo altamente paralelo, com suporte a multithreading 2, com muitos processadores de alto desempenho e com largo barramento do memória. O grande desafio é desenvolver aplicações que permitam usar a capacidade de escalar em grau de paralelismo e, assim, aproveitar o aumento constante do número de núcleos de processamento. Devido a sua estrutura altamente paralela as GPUs estão deixando de ser dispositivos exclusivos para o processamento de aplicaçõs gráficas, e começam a ser utilizadas para realizar o processamento de aplicações de propósito geral. A Programação de propósito geral em 1 em inglês, Graphics Processing Unit 2 Capacidade de executar vários processos simultâneamente

9 2 GPU (GPGPU 3 ) tem como objetivo aproveitar todo o poder de processamento das GPUs que atualmente possuem centenas de processadores independentes e diferentes tipos de memórias. Os primeiros programas de propósito geral que aproveitavam o potencial das GPUs foram escritos através de APIs 4 desenvolvidas exclusivamente para a computação gráfica, como é o caso das bibliotecas gráficas OpenGL 5 e Direct3D 6 que por muito tempo foram a única forma de criar programas capazes de utilizar as GPUs. Porém o modelo de programação voltado para aplicações gráficas era muito confuso e não se mostrou ideal a programação de propósito geral. Assim foram desenvolvidos modelos de programação de propósito geral para permitir que o hardware das GPUs fosse utilizado. O modelo desenvolvido pela NVidia é o Compute Unified Device Architecture (CUDA 7 ). O objetivo desse modelo é simplificar a programação em GPU para que o programador possa se concentrar no paralelismo. Isso é possível porque a API desenvolvida abstrai o hardware da GPU enquanto bibliotecas na linguagem C simplificam o acesso aos recursos do dispositivo. A ATI desenvolveu um modelo semelhante ao da NVidia, o Close to Metal (CTM) [PEERCY; SEGAL; GERSTMANN, 2006]. O CTM permite que o desenvolvedor acesse o conjunto nativo de instruções diretamente e, com isso, tenha mais flexibilidade no desenvolvimento e obtenha o melhor desempenho de seu hardware. Além dessas, outras APIs, como a RapidMind 8 que implementa abstrações das GPUs Intel e AMD, foram criadas para possibilitar a programação de propósito geral em GPUs. Este trabalho apresenta o estudo do modelo programação paralela CUDA e do padrão MPEG-1 Layer III 9 de compressão de áudio para demonstrar que o paralelismo das GPUs pode ser aplicado na criação e na melhoria de técnicas que permitam melhorar o desempenho de sistemas multimídia. O objetivo do trabalho é propor um modelo de Servidor de Áudio que permita a implementação de um Servidor de Áudio que utilize o processamento em GPU. E, 3 em ingês, General Purpose computing on Graphic Processing Units 4 API, Application Programming Inteface, é o conjunto de rotinas e padrões definidos por um software para utilização de suas funcionalidades em inglês, Compute Unified Device Architecture O padrão MPEG-1 Layer III também é conhecido como MP3

10 3 com isso, possa demonstrar que a implementação de técnicas de processamento de áudio em GPU, especialmente utilizando o modelo CUDA, é viável. O capítulo 2 introduz conceitos da programação paralela necessários para em seguida entender o modelo de programação CUDA. O capítulo 3 introduz os conceitos do Áudio Digital relevantes a este trabalho, apresenta um estudo do padrão MPEG-1 Layer III e faz uma breve apresentação do codificador LAME. O capítulo 4 apresenta um modelo de Servidor de Áudio e uma implementação baseada no modelo, que utiliza um codificador de áudio implementado em partes em CUDA. Além disso são analisados os resultados dos testes realizados com o codificador e com o Servidor de Áudio implementado. Por fim, o capítulo 5 conclui o trabalho.

11 4 2 Programação Paralela A programação paralela em geral é relacionada com o aumento de desempenho, uma vez que permite mais de uma execução simultaneamente. Porém esse aumento de desempenho está associado ao grau de paralelismo de cada programa, ou seja, a capacidade de cada programa executar suas instruções ou seu código ao mesmo tempo. Neste capítulo serão abordados os tipos de paralelismo para introduzir os conceitos necessários à programação paralela e, em seguida, um estudo do modelo de programação CUDA. Uma revisão da API do modelo CUDA encontra-se no anexo A. 2.1 Paralelismo em Nível de Instrução Desde 1985, os processadores utilizam a sobreposição da execução de instruções através da técnica de pipelining para melhorar seu desempenho [HENNESSY; PATTERSON, 1990]. A esta sobreposição de execuções se dá o nome de Paralelismo em Nível de Instrução. Com isso é possível permitir que duas instruções seriais sejam executadas de forma paralela, uma vez que nem toda instrução depende de sua antecessora. A maior limitação do Paralelismo em Nível de Instrução é a dependência entre as instruções, isso significa que muitas vezes uma instrução deve esperar um ou mais estágios até que outra instrução disponibilize o dado necessário por ela. Aumentar o paralelismo em nível de instrução significa diminuir o nível de dependência entre as intruções.

12 5 2.2 Multiprocessadores e Paralelismo em Nível de Thread A afirmação de que os processadores convencionais estão chegando a seus limites físicos pode ser constatada pela desaceleração da melhora de desempenho destes processadores e pela redução da melhora de desempenho trazida pelo paralelismo em nível de instrução. Ou seja, a melhora de desempenho dos processadores é cada vez menor e o paralelismo em nível de instrução melhora cada vez menos o desempenho desses dispositivos. Com isso, os multiprocessadores passam a desempenhar o papel principal na arquitetura de computadores para continuar a melhorar o desempenho dos computadores. Além disso a tendência por trás dos multiprocessadores é reforçada por outros fatores: Aumento no interesse em servidores e no desempenho dos servidores; Crescimento no número de aplicações de processamento intenso de dados; Melhora no entendimento de como usar os multiprocessadores de uma forma eficiente; Porém, existem dois problemas: a arquitetura de multiprocessadores é um campo extenso e diverso que em sua maior parte é novo e com muitas idéias [HENNESSY; PATTERSON, 1990]. E uma grande abrangência implica necessariamente em discutir abordagens que podem não permanecer com o tempo. Uma Thread, ou processo leve, é uma linha de execução de um programa que possui suas próprias variáveis de controle como o contador 1 e outras estruturas, porém ela compartilha o mesmo código e pode compartilhar a mesma região de dados com outras threads. O advento dos multiprocessadores permite um paralelismo real no qual as threads executam em processadores diferentes simultaneamente ao invés de alternarem sua execução no mesmo processador. Não há dependência entre threads, portanto elas podem executar de forma livre umas das outras. 1 Program Counter (PC)

13 6 Figura 2.1: Exemplo de Soma Paralela de um Vetor 2.3 Paralelismo em Nível de Dados No Paralelismo em Nível de Dados os dados são divididos em partes que são executadas paralelamente em unidades de processamento diferentes. O exemplo mais simples do paralelismo em nível de dados é o incremento paralelo dos valores de um vetor. Como exemplificado na Figura 2.1, que mostra a aplicação paralela de uma função que soma 4 (representada pelos círculos) ao valor de cada posição de um vetor. Dessa forma, o tempo de execução de todas as somas equivale a execução de uma única soma, pois todas são executadas ao mesmo tempo em unidades de processamento diferentes. As GPUs foram desenvolvidas para utilizar esse tipo de paralelismo e permitir o processamento de grandes quantidades de dados simultaneamente. 2.4 Compute Unified Device Architecture (CUDA) Com a compra da ATI pela AMD, a NVidia permaneceu como a maior empresa desenvolvedora exclusivamente de GPUs. Com isso a concorrência pelo mercado de GPUs se concentrou nos três principais desenvolvedores: A Intel, a AMD e a NVidia. Porém, a Intel e a AMD, como produtoras de CPUs 2, pretendem integrar núcleos gráficos aos seus processadores em um futuro breve [HALFHILL, 2008]. Essa integração pode fazer o mercado de placas gráficas reduzir, pois a venda desse tipo de dispositivo se restringiria a aplicações que 2 Central Processing Unit em inglês, ou Unidade Central de Processamento

14 7 necessitam de um desempenho gráfico realmente alto. Por outro lado, já existem placas gráficas vendidas integradas ao computador, portanto as conseqüências da integração de núcleos gráficos às CPUs não deve ser tão graves. Com isso a NVidia encontrou na GPGPU 3 uma forma de se diferenciar no mercado e aproveitar ainda mais a capacidade de processamento de suas GPUs. Porém os modelos de programação GPGPU existentes eram muito complexos. Esses modelos haviam sido criados para o processamento gráfico (OpenGL e Direct3D). E mapear um problema de propósito geral para o domínio gráfico nem sempre é uma tarefa simples. Além disso, o resultado final depende do mapeamento escolhido. Portanto, os modelos existentes se mostraram inviáveis para a programação GPGPU. Assim, a NVidia aproveitou a oportunidade de criar um novo modelo de programação GPGPU. E então surgiu o CUDA. CUDA, em inglês, Compute Unified Device Architecture, é a API que implementa o novo modelo de programação GPGPU desenvolvido pela NVidia. Seu objetivo é proporcionar um ambiente de programação simples, por isso CUDA implementa um mecanismo de abstração do hardware da GPU através de bibliotecas de funções nas linguagens C/C++. CUDA permite que o programador mantenha o foco na programação paralela, pois não requer o gerenciamento convencional de threads, esse gerenciamento é abstraído pela API. Além disso, a API permite que programas desenvolvidos em CUDA não deixem de funcionar devido a atualização do harware [NVIDIA, 2008]. CUDA é uma solução para o paralelismo real em nível de thread com alto número de processadores que possui uma arquitetura amplamente difundida. Além disso a GPU é especialmente adequada para resolver problemas que podem ser expressados por computação de dados paralela (ou seja, o mesmo programa é executado em vários elementos de dado paralelamente - paralelismo em nível de dados) com alta intensidade aritmética (taxa de operações aritméticas em relação a taxa de operações de memória). Como o mesmo programa é executado para cada elemento de dado, a necessidade de fluxos de controle sofisticados é baixa. Portanto, o modelo de programação CUDA se mostra adequado para utilizar de forma eficiente 3 Programação de Propósito Geral em Unidades de Processamento Gráfico (GPU), em inglês, General Propose computing on Graphics Processing Units

15 8 Figura 2.2: Modelo da Arquitetura NVidia (GeForce 8) [HALFHILL, 2008] o paralelismo das GPUs Escondendo Processadores NVidia sempre escondeu a arquitetura de suas GPUs através de uma API. Como resultado disso, os programas não acessam o hardware diretamente. Ao invés disso, as funções que manipulam diretamente o hardware estão implementadas na API. A figura 2.2 mostra um modelo da arquitetura GPU que serviu como base para o modelo da API de programação em CUDA. As threads são executadas nos processadores de threads 4 e gerenciadas pela própria arquitetura de forma transparente ao usuário. Funções CUDA, chamadas de kernel 5, são executadas em paralelo 6 por um conjunto de processadores de threads e possuem acesso a alguns tipos de memória, incluindo a memória principal da GPU e uma memória compartilhada entre conjuntos de processadores. Além disso, CUDA permite uma programação heterogênea, ou seja, a programação pode ser dividida entre a CPU e a GPU de forma que o código C serial seja executado em CPU, enquanto kernels paralelos em CUDA executam em GPU. 4 do inglês, Thread Processors. Também são conhecidos por Stream Processors. Na arquitetura de GPU eram conhecidos como Shaders 5 Um Kernel consiste em uma função CUDA que contém o código que será executado em GPU 6 Paralelismo em nível de Thread [HENNESSY; PATTERSON, 1990]

16 Gerenciamento de Threads As threads em CUDA são identificadas por blocos, ou seja, cada bloco possui um conjunto de threads que executam o mesmo trecho de código de forma independente entre si. Os blocos de threads podem ser unidimensionais, bidimensionais ou tridimensionais. As threads de um mesmo bloco podem cooperar, pois têm acesso à mesma memória compartilhada. Além disso, existem funções definidas na biblioteca CUDA que implementam barreiras [SILBERS- CHATZ; GALVIN, 2000] para sincronizar a execução das threads. O número de threads por bloco é limitado pelos recursos de memória. Os blocos de um kernel em CUDA são identificados por grids, que podem ser unidimensionais ou bidimensionais. As threads de cada bloco em um grid executam de forma independente das threads dos outros blocos. A arquitetura Tesla [NVIDIA, 2008] implementada nas placas NVidia mais recentes é baseada em um vetor de multiprocessadores 7. Quando um programa CUDA executando em CPU chama o grid de um kernel, os blocos do grid são ordenados e distribuídos aos multiprocessadores da GPU. As threads de um bloco executam concorrentemente em um multiprocessador. Ao terminar a execução de um bloco, novos blocos são lançados para ocupar os multiprocessadores vagos. Na arquitetura Tesla, um multiprocessador consiste em 8 núcleos de processamento escalar 8. O multiprocessador cria, gerencia e executa threads concorrentes em hardware sem overhead de escalonamento. Ele também implementa barreiras de sincronização com uma única instrução. Para gerenciar centenas de threads executando diferentes programas, o multiprocessador implementa um novo tipo de arquitetura chamada de SIMT (Single Intruction, Multiple Thread). O multiprocessador mapeia cada thread para um núcleo de processamento. E cada thread executa de forma independente com seu próprio endereço de instrução e registradores. 7 em inglês, Streaming Multiprocessors 8 em inglês, Scalar Processor

17 10 O SIMT cria, gerencia e executa threads em grupos de até 32 threads paralelas, chamadas warps. As threads que compõe um warp iniciam juntas no mesmo endereço, mas são livres para executar independentemente. Quando um multiprocessador recebe conjunto de um ou mais blocos para executar, ele o divide em warps que serão escalonados pelo SIMT. A cada instrução, o SIMT seleciona um warp que está pronto para executar e passa para a próxima instrução nas threads ativas. Um warp executa uma instrução comum por vez, assim, quando todas as threads estão executando juntas, isto é, de forma semelhante, o warp é executado com maior eficiência Hierarquia de Memória De forma semelhante à arquitetura do SIMT, que gerência as threads, o multiprocessador implementa o SIMD (Single Instruction, Multiple Data), que com uma instrução simples controla o processamento de vários elementos. Como ilustrado na figura 2.3, cada thread pode acessar 4 tipos de memória. Cada thread possui uma memória local privada e um conjunto de registradores de 32 bits. Cada bloco de threads possui uma memória compartilhada 9 visível a todas as threads do bloco. Todas as threads do dispositivo possuem acesso à mesma memória global 10, que é a memória principal da GPU. E existem também as memórias de Constante 11 e de Textura 12 que são acessíveis a todas as threads. São memórias somente-leitura otimizadas utilizadas para a entrada de dados externos ao dispositivo o que permite o acesso indireto à memória RAM da máquina 13. Um programa pode manipular as memórias global, de contante e de textura através da biblioteca CUDA. Isso inclui alocação de memória, liberação de memória alocada, assim como a transferência entre a memória do computador e do dispositivo. O número de blocos que um multiprocessador comporta depende de quantos regis- 9 Shared memory 10 em inglês, Device Memory 11 Constant memory 12 Texture memory 13 Host Memory

18 11 Figura 2.3: Hierarquia de Memória em CUDA tradores por thread e quanta memória compartilhada por bloco são necessários para um dado kernel. Se não houver registradores ou memória compartilhada suficiente por multiprocessador para processar pelo menos um bloco, o kernel irá falhar. Se uma instrução executada por um warp escreve na mesma posição de memória para mais de uma thread do warp, a ordem que as escritas ocorrem é indefinida.

19 12 3 Áudio Digital Um sinal analógico de áudio é um sinal elétrico que representa as vibrações mecânicas do ar. Tais sinais possuem duas dimensões que representam a pressão do ar variando de acordo com o tempo. Os sistemas analógicos, utilizam a voltagem do sinal elétrica para representar a variação da pressão do ar. Porém os sistemas analógicos são bastante vulneráveis a distorções de sinal [WATKINSON, 2001]. O áudio digital é simplesmente um meio alternativo de transportatr um sinal de áudio. Embora existam várias maneiras de implementar isso, há um sistema conhecido por Pulse Code Modulation (PCM [POHLMANN, 2000]), que é amplamente utilizado. No sistema PCM, o tempo é representado de forma discreta. Dessa forma, o sinal de áudio não é composto por uma representação contínua, mas por medidas em intervalos regulares. Este processo é chamado de amostragem e a freqüência cujas amostras são medidas é chamado de taxa de amostragem. Cada amostra ainda varia infinitamente como o sinal original, porém, assim como o tempo, sua representação é um valor discreto. E para completar a conversão para o formato PCM, cada amostra é representada por um valor discreto em um processo chamado quantização. Esse processo consiste em representar a pressão do áudio no instante da captura em um valor de amostra. Além de não ser tão vulnerável a distorções, a representação de áudio em formato digital ofecere várias vantagens [PAN, 1993], como a reprodutibilidade, e ainda permite a aplicação de implementações eficientes para várias funções de processamento de áudio.

20 Processamento de Áudio Digital O processamento de áudio digital 1 é empregado na gravação e armazenamento de áudio, para mixagem de sons e produção de programas de tv, assim como em produtos comerciais como CDs. O áudio digital é, de uma forma digital, todo o caminho do microfone até os alto-falantes, onde procesadores de sinais digitais eficientes permitem o processamento em tempo-real. Através do processamento de áudio é possível modelar o conjunto de amostras de áudio de forma a se obter os efeitos desejados. Com o processamento de áudio é possível obter [ROADS et al., 1996]: Manipulação a dinâmica da amplitude do som; Mixagem para combinar várias faixas de áudio; Filtros e equalizadores para modificar o espectro de freqüência de um som; Efeitos de atraso (time-delay); Convolução, transformações simultâneas nos domínios do tempo e da freqüência; Projeção espacial, incluindo reverberação; Redução de ruído. 3.2 Compressão de Áudio A Compressão de Áudio Digital utiliza de técnicas de processamento de áudio para permitir o armazenamento e a transmissão de informação de áudio de forma eficiente [PAN, 1993]. Otimizar o processo de compressão de áudio permite aumentar a variedade de aplicações para o áudio digital. Isso inclui os dispositivos de música portáteis; o áudio para cinema; rádio e televisão digital de alta qualidade; aparelhos de DVD e muito mais [CAVAGNOLO; BIER, ]. 1 Processamento de Sinais de Áudio Digital

21 14 As técnicas de compressão de áudio diferem pela complexidade de seus algoritmos, pela qualidade da compressão do áudio e pela quantidade de dados comprimidos. Técnicas simples como a transformação µ-law 2 [PAN, 1993] e a modulação diferencial adaptaviva por códigos de pulsos (ADPCM 3 ) [PAN, 1993] podem ser facilmente implementados para processar áudio em tempo-real. O desafio é desenvolver uma implementação em tempo-real para o padrão de áudio MPEG-1 layer III [PAN, 1995]. As próximas seções explicam alguns dos conceitos mais importantes do padrão MPEG-1 Layer III. 3.3 O padrão MPEG-1 Layer III O MPEG, Motion Pictures Experts Group, é o grupo formado pela ISO 4 para definir padrões de compressão e transmissão de áudio e vídeo. Os padrões MPEG cobrem diferentes aspectos. Dentre eles, o padrão MPEG-1, foi o primeiro a definir a codificação do áudio. O padrão MPEG-1 de áudio efetua a compressão do áudio baseado nas limitações físicas da audição humana. O ouvido humano é capaz de detectar sons em uma faixa de freqüência que varia de 20Hz a 20KHz. De forma que, não faz sentido armazenar todos os dados referentes a freqüências fora dessa faixa. Além disso, dentro da faixa de freqüências audíveis, a percepção da audição humana obedece à uma curva (Figura 3.2) onde a percepção da intensidade de um som varia com a freqüência. E, por fim, o ouvido humano não consegue captar todos os sons simultaneamente, o que é conhecido como efeito de mascaramento de sons, onde alguns sons são escondidos por outros mais fortes. Ou seja, o padrão MPEG-1 de áudio se utiliza das limitações da percepção da audição humana para eliminar informações de áudio sem causar alterações perceptíveis, sendo por isso conhecido também como um algoritmo de codificação perceptiva. No padrão MPEG-1 Layer III, o áudio capturado no formato PCM passa por um banco de filtros que decompõe 1152 amostras 5 PCM do áudio em 32 sub-bandas de freqüências de 2 algorithm 3 Adaptative Differential Pulse-Code Modulation 4 International Organization for Standardization 5 Um quadro MP3 é composto de 1152 amostras PCM

22 15 Sinal Digital de Áudio(PCM) Quantificação não-uniforme Sinal de Áudio Codificado Banco de Filtros MDCT Controle de Distorção Controle de Taxa Codificação de Huffman Formatação da Seqüência de Bits FFT Modelagem Psicoacústica Figura 3.1: Processo de Codificação MP3 mesma largura. Após esse processo, a Transformada Discreta de Cosseno Modificada [PRIN- CEN; BRADLEY, 1986] (MDCT 6 ) é aplicada a cada amostra de cada sub-banda. Com isso, as sub-bandas, que pertencem ao domínio do tempo, serão mapeadas para o domínio da freqüência. Enquanto isso, aplica-se a Transformada Rápida de Fourier [DUHAMEL; VETTERLI, 1990] (FFT 7 ) nas amostras originais para revelar seu espectro sonoro. O espectro, por sua vez, passa pela modelagem psicoacústica que determina a taxa de energia 8 do sinal para o limiar de mascaramento de cada sub-banda, que será utilizada na fase de quantificação. O bloco de controle de distorção utiliza as taxas da relação sinal / mascaramento (SMR 9 ) do modelo psicoacústico para decidir quantos bits disponibilizar para a quantificação dos sinais das sub-bandas para reduzir o ruído de quantificação. Em seguida as amostras quantificadas passam pela codificação de Huffman [HUFFMAN, 1952] para reduzir a entropia das amostras. Por fim, as amostras codificadas e suas informações são empacotadas. As subseções a seguir descrevem os detalhes das principais operações realizadas. O processo descrito acima está ilustrado na Figura Banco de Filtros Polifásicos de Análise O primeiro passo do processo de codificação é a passagem do sinal de áudio PCM por um banco de filtros. O Banco de Filtros Polifásicos de Análise tem como objetivo decompor o sinal em 32 sub-bandas. Essa decomposição agrupa as amostras de sub-banda da mesma forma 6 Modified Discret Cosine Transform 7 Fast Fourier Transform 8 Nível de pressão do ar determinada pelo sinal, em decibéis (db) 9 Signal-to-Mask Ratio

23 16 que no sinal original, porém pode causar algumas distorções 10. A seqüência de 1152 amostras PCM de áudio de um quadro MP3 são filtradas de maneira que cada sub-banda possua 36 amostras. O resultado do banco de filtros é definida pela seguinte equação: S[i] = 63 k=0 7 M[i][k] (C[k + 64 j] X[k + 64 j]) j=0 Onde i é o índice de cada uma das 32 sub-bandas; S[i] é a amostra resultante para a sub-banda i e tempo 11 t; C[n] é um dos 512 coeficientes da janela de análise definida pelo padrão [PRINCEN; BRADLEY, 1986]; X[n] é uma amostra de áudio de um buffer de amostras de 512 posições; M[i][k] é a matriz de coeficientes da análise que é definido pela equação: M[i][k] = cos[ (2 i + 1) (k 16) π ] 64 Esse conjunto de equações está otimizado para reduzir o número de cálculos. Para melhorar o entendimento desse cálculo, essas equações podem ser simplificadas na seguinte equação de convolução: St[i] = 511 X[t n] Hi[n] n=0 Onde X[t] representa uma amostra de áudio no tempo t. H[i] que é definido pela equação H[i] = h[i] cos[ (2 i+1) (n 16) π 64 ], representa o filtro responsável por decompor o áudio em sub-bandas de freqüência adequadas, por isso é chamado de filtro polifásico. E, por fim, h[n] é definido por C[n] se o resultado de n/64 for ímpar, caso contrário h[n] = C[n]. 10 Aliasing [VAIDYANATHAN, 1987] 11 O tempo t é representado por um inteiro múltiplo de 32 intervalos de amostra

24 Transformação Discreta de Cosseno Modificada Nesse processo, as amostras das 32 sub-bandas recebidas do banco de filtros são mapeadas em uma transformação discreta de cosseno modificada (MDCT). Como resultado, as amotras, que pertencem ao domínio do tempo, serão mapeadas no domínio da freqüência. Antes de computar a MDCT, quatro funções janela 12 são aplicadas às amostras. Funções janela, são funções utilizadas em processamento de sinais para melhorar a eficiência da análise do espectro de onda (espectro sonoro no caso do processamento de áudio). O padrão MPEG-1 Layer III especifica dois tamanhos de blocos MDCT: o bloco longo de 18 amostras e o bloco curto de 6 amostras. Há 50% de sobreposição entre sucessivas janelas de transformadas uma vez que o tamanho da janela é 36 ou 12 respectivamente. Da mesma forma, dependendo da dinâmica de cada sub-banda são usadas janelas longas ou curtas. Se as amostras de uma dada sub-banda se comportam de forma estacionária, a janela regular, longa, é usada. Se as amostras são transitórias, a janela curta é aplicada para subdividir o resultado da sub-banda em freqüência e intensificar a resolução de tempo. Este mecanismo ajuda a evitar o aparecimento do fenômeno de pré-eco 13, o que pode acontecer quando aplicamos a FFT sobre um conjunto de amostras. O efeito de pré-eco ocorre quando há uma demanda muito alta de bits em um curto espaço de tempo (por exemplo, um momento de silêncio seguido de um ataque abrupto), e com isso o ruído de quantização exagerado de um determinado trecho de áudio é espalhado para instantes anteriores à sua ocorrência causando um ruído audível no sinal codificado, nos instantes anteriores à ocorrência do ataque. As outras duas janelas utilizadas para manipular as transições de longo para curto ou de curto para longo são chamadas de janela de início e janela de parada, respectivamente. O bloco curto é um terço do bloco longo, de forma que três blocos curtos substituem um bloco longo. O número de amostras de um quadro de amostras não é alterado pela tamanho do bloco. Para um dado quadro de amostras, a MDCT possui 3 modos de blocos, 2 modos com o mesmo tamanho de blocos (longos ou curtos) e um modo misto, onde as duas sub-bandas de mais baixa freqüência usam blocos de longos e as 30 sub-bandas de mais 12 function 13 echo

25 18 alta freqüência utilizam blocos curtos. Assim é possível fornecer melhor resolução para as freqüências mais baixas, sem sacrificar as resolução de tempo para as freqüências mais altas Modelagem Psicoacústica A modelagem psicoacústica é o componente chave para o desempenho do codificador. Com ela é possível simular a percepção do som pelo sistema auditivo humano. Na codificação, a modelagem psicoacústica decide quais partes são acusticamente irrelevantes e quais não são, e remove as partes inaudíveis. Para isso, ela se aproveita da falta habilidade do sistema auditivo humano em ouvir sons quantificados sobre um mascaramento. O mascaramento é uma propriedade do sistema auditivo humano que ocorre quando um sinal de áudio forte se encontra próximo de um sinal de áudio mais fraco no espectro ou no tempo, tornando o sinal de áudio mais fraco imperceptível. O limiar absoluto de audição 14 consiste na quantidade mínima de energia necessária para um tom puro ser detectado em um ambiente silencioso. Se a energia de um número de tons de freqüência for medida, obtêm-se o gráfico da figura 3.2. Isso significa que todos os valores abaixo da linha do gráfico não podem ser detectados. O mascaramento de freqüência é um fenômeno que torna um sinal de baixa freqüência inaudível pela ocorrência simultânea de um sinal mais forte em uma freqüência suficientemente próxima. O limiar do mascaramento de freqüência pode ser medido e qualquer sinal abaixo dele não será audível, como demonstra o gráfico da Figura 3.3. O limiar depende da intensidade sonora e da freqüência da máscara. Com isso é possível intensificar o ruído de quantificação de uma sub-banda o que significa que menos bits serão necesários para representar o sinal nessa sub-banda. Além do mascaramento no domínio da freqüência, também existe o mascaramento temporal. Isso acontece quando dois sons aparecem em um intervalo muito pequeno de tempo. O som mais forte pode mascarar o mais fraco. Os efeitos do mascaramento temporal aconte- 14 Absotute Threshold of Hearing(ATH)

26 19 Figura 3.2: Limiar Absoluto de Audição cem antes e depois de um som forte. Um som pode sofrer de pós-mascaramento, quando isso acontece após um som mais forte, ou pré-mascaramento, quando o som mais forte ocorre logo em seguida. O pré-mascaramento pode prevenir a ocorrência de pré-eco Quantificação não-uniforme O bloco de Quantificação não-uniforme recebe o resultado da MDCT, uma janela de mudança e informações de mascaramento da modelagem psicoacústica para efetuar a quantificação. O resultado é um dado codificado de acordo com as limitações da audição humana. A Quantificação não-uniforme é a parte que mais consome tempo no algoritmo de codificação. Ela é dividida em três níveis: A execução do bloco de Quantificação não-uniforme que executa o loop externo, responsável pela análise da distorção, que, por sua vez, executa o loop interno que é responsável pela quantificação e codificação. Como demonstrado na Figura 3.4, as amostras das sub-bandas são quantificadas em um processo iterativo. O loop interno quantifica a entrada e incrementa o passo do quantificador até que os dados possam ser codificados com um certo número de bits. Após a execução do loop

27 Nível de Pressão do Ar 20 Máscara Limiar de audição modificado Sinal não Mascarado Sinais Mascarados Freqüência Limiar de Audição Figura 3.3: Mascaramento de Freqüência interno, o loop externo faz a verificação de cada fator de escala da sub-banda, se a distorção permitida for excedida, o fator de escala é incrementado e o loop interno é executado novamente. O loop externo, também conhecido como loop de controle de distorção, controla o ruído produzido pela quantificação no loop interno. O ruído é eliminado pela multiplicação das amostras por um fator de escala. O loop externo é executado até que o ruído permaneça abaixo do limiar de mascaramento para cada fator de escala da sub-banda. O loop interno, ou loop de controle de taxa, realiza a quantificação do áudio no domínio da freqüência e o prepara a operação de formatação. A tabela do código de Huffman atribui palavras menores aos menores valores quantificados. O número total de bits resultados da codificação pode exceder o número de bits disponíveis em um quadro, isso pode ser corrigido ajustando o ganho global para resultar em um passo de quantificação maior e, conseqüentemente, um valor quantificado menor. Essa operação é repetida com diferentes tamanhos de passos de quantificação até que o número de bits necessários pela codificação de Huffman seja suficientemente pequeno.

28 21 Amostras de Sub-banda Quantificação Loop Externo Ajusta o fator de escala e volta ao loop interno, Repete enquanto o ruído da quantificação não for aceitável Loop Interno Ajusta o ganho até que o valor quantificado seja menor que o bitrate Codificação de Huffman bitrate S Compara o ruído de quantificação de cada sub-banda com o limiar de mascaramento S Áudio Codificado Ajuste Global de Ganho Ajuste do Fator de escala Codificação de Huffman Figura 3.4: Quantificação não-uniforme Dependendo da implementação, a codificação de Huffman baseada em 32 tabelas estáticas de Huffman é efetuada durante ou após a quantificação. A codificação de Huffman fornece uma compressão sem perda de dados, portanto é capaz de reduzir o tamanho sem perda de qualidade. Na Codificação de Huffman a entropia é baseada na distribuição estatística de um grupo de valores. Uma tabela de substituição cobrindo todos os valores é estabelecida a partir dos dados estatísticos. Nessa tabela, os valores com maiores possibilidades de aparecerem nos dados são associados a uma palavra menor e dados que raramente aparecem são associados a palavras maiores. Entretanto, a codificação de Huffman é um código de tamanho variável e portanto a construção da tabela de códigos não é uma tarefa trivial. As amostras são ordenadas pela freqüência e então divididas em três faixas distintas. Isso permite que cada faixa seja codificada com um conjunto diferente de tabelas específicamente ajustadas para as estatísticas de cada faixa Formatação da Seqüência de Bits A última parte da codificação consiste na produção da seqüência de bits compatível com o padrão MPEG-1 Layer III. A seqüência de bits é particionada em quadros que represen-

29 22 tam 1152 amostras PCM. O cabeçalho descreve a taxa de bits e a freqüência de amostragem usadas para o audio codificado. Informações como tipo de bloco, tabelas de huffman, ganho de sub-banda e fatores de sub-banda são selecionados. Uma técnica utilizada para ajustar a variação do tempo de codificação é a utilização de um reservatório de bits. O codificador pode doar alguns bits quando ele precisa de menos do que a média de bits necessária para codificar um quadro. Em seguida, quando o codificador precisar de mais bits, ele pode emprestar do reservatório. O codificador pode emprestar apenas bits doados de quadros passados, não pode emprestar de quadros futuros. 3.4 LAME Ain t an Mp3 Encoder Considerado um dos melhores, se não o melhor, codificador MP3, o LAME 15 (acrônimo recursivo de LAME Ain t an Mp3 Encoder) iniciou em 1998 como um projeto open source que visava melhorar o modelo psicoacústico, a eliminação de ruído e o desempenho do codificador dist10 16 da ISO, que é a implementação do padrão MPEG-1 Layer III. Portanto, a princípio, o LAME não era tecnicamente um codificador (por isso o seu nome), apenas uma tentativa de melhorar o codificador da ISO. Para evitar problemas legais, o LAME foi desenvolvido sob uma licensa aberta (a LGPL) ao contrário do código da ISO e da patente da organização de pesquisa alemã Fraunhofer-Gesellschaft 17, que desenvolveu o algoritmo de compressão MP3. Em 1999, o projeto apresentou seu próprio modelo psicoacústico, chamado de GPSYCHO, que tem como objetivo melhorar o modelo da ISO. Finalmente, em Maio de 2000, todo o código da ISO havia sido reescrito e o LAME surgiu com seu próprio codificador desenvolvido pela equipe de programadores open source por trás do projeto LAME. 15 lame.sourceforge.net 16 padrão ISO

30 23 4 Processamento de Áudio em GPU É possível melhorar a eficiência das técnicas de processamento de áudio, como a compressão de áudio digital, através do desenvolvimento do hardware, do desenvolvimento de novas técnicas de processamento de sinais ou de melhorias nas técnicas existentes. Nesse sentido a programação de propósito geral em GPU pode ser vista como um meio para tornar algoritmos de processamento de áudio digital mais eficientes através do paralelismo desses dispositivos. Dessa forma o hardware das GPUs pode ser usado para incrementar o desempenho dos algoritmos apenas com algumas modificações nas técnicas de processamento de áudio existentes e sem a necessidade de desenvolver novas técnicas de processamento de sinais. Neste trabalho propomos a implementação de Servidor de Áudio que utiliza a programação paralela em GPUs do modelo CUDA para melhorar o desempenho do processamento do áudio. Para demonstrar que essa abordagem é possível, as próximas seções deste capítulo descrevem um modelo de servidor de áudio que captura o áudio de um microfone, processa o áudio e transmite o áudio processado a um cliente que, após conectado ao servidor, recebe o áudio, realiza um novo processamento, se necessário, e reproduz o áudio. Também é descrita a implementação de um servidor de áudio baseado nesse modelo. O processamento de áudio realizado por essa imlpementação é a codificação do áudio capturado. Para melhorar o desempenho da codificação, o codificador foi modificado a fim de ter sua execução paralelizada através da implementação de funções em CUDA.

31 Modelo de Servidor de Áudio Este trabalho começou como um estudo do modelo CUDA de programação paralela em GPU e uma análise das possíveis aplicações para tal tecnologia. Entre as possíveis aplicações para o processamento paralelo em GPU citadas estão: algoritmos genéticos, criptografia [MA- NAVSKI., 2007], compactação, processamento de imagens, processamento de áudio, reconhecimento de fala [CHONG et al., 2008] e VoIP. Por fim, foi decidido que este trabalho deveria desenvolver um modelo de Servidor de Áudio e aplicar o processamento em GPU. Dessa forma, foi possível unir as propostas de trabalhar com redes de computadores, processamento paralelo em GPU e processamento de áudio. O modelo proposto consiste em um servidor que captura o sinal analógico do áudio de um microfone e converte-o para o formato digital através de uma biblioteca de áudio, representada na Figura 4.1 pela Captura de Áudio. Após a captura, o áudio, já no formato digital, é processado utilizando uma técnica de processamento de áudio implementado em CUDA. Essa etapa corresponde ao Processamento de Áudio na Figura 4.1. Em seguida, o áudio processado é enviado para um cliente através de um protocolo de rede. Essa comunicação entre o servidor e o cliente está representada na Figura 4.1 pela Transferência do Áudio Processado. O cliente, então, recebe os dados do servidor e realiza um novo processamento, caso seja necessário. E, por fim, o áudio digital é convertido em um sinal analógico para ser executado pelas caixas de som do cliente. Essa ação é representada na Figura 4.1 pela Reprodução do Áudio. Esse modelo de Servidor de Áudio serve como base para demonstrar a utilização do modelo CUDA de programação paralela em GPU para realizar o processamento de áudio. E dessa forma mostrar que a programação paralela em GPU pode ser utilizada como um meio de melhorar o desempenho de técnicas de processamento de áudio existentes, como por exemplo, a codificação de áudio.

32 25 Processamento do Áudio Envio Processado Processamento do Áudio Figura 4.1: Modelo de Servidor de Áudio 4.2 Um Servidor de Áudio com codificação em GPU A primeira implementação do modelo desenvolveu um Servidor de Áudio que utiliza a biblioteca ALSA 1 para capturar o sinal analógico de áudio do microfone e convertê-lo no formato PCM de 16 bits little-endian sinalizado; ou seja, cada amostra de áudio possui valores entre e 32767; em apenas um canal (mono); com taxa de amostragem de 44100Hz, isso significa que são capturadas amostras de áudio por segundo. E, além disso, o Servidor de áudio possui um socket 2 configurado com o protocolo UDP [POSTEL, 1980] para enviar os dados do áudio para um cliente. Foi implementado também um cliente que se conecta ao servidor através do mesmo protocolo de rede, recebe o áudio do servidor e reproduz o áudio digital utilizando o ALSA. O algoritmo do servidor consiste em capturar e enviar o áudio para o cliente, esses procedimentos são executados repetidamente nessa ordem de até que a execução do servidor seja interrompida pelo usuário. Da mesma forma o cliente recebe e reproduz o áudio do servidor, esses procedimentos também são executados nessa ordem até que o servidor pare 1 Advanced Linux Sound Architecture 2 socket

33 26 de enviar mais dados, pois a função de recebimento de dados do cliente é bloqueante. Com essa implementação é possível capturar o áudio em formato digital e reproduzí-lo em outra máquina. Porém essa implementação não representava o modelo proposto, pois não realizava nenhum processamento de áudio entre a captura e a reprodução do áudio. Para que a implementação correspondesse ao modelo era necessário a implementação alguma técnica para processar o áudio do Servidor de Áudio implementado. Depois de analisar algumas alternativas, como a criptografia do áudio, foi decidido que o processamento seria uma codificação do áudio capturado. Dessa forma, foi possível reduzir a quantidade de dados enviados para o cliente e, portanto, melhorar a qualidade do áudio capturado sem aumentar o tempo de envio do áudio para o cliente. Então, foram pesquisados alguns codificadores de áudio, entre eles o Speex 3, que é um codificador de áudio especializado em fala 4. Porém o codificador escolhido foi o LAME. Pois, dessa forma, foi possível aproveitar a documentação do concurso da NVidia de implementação do codificador LAME em CUDA 5. Na página do concurso, a NVidia disponibiliza uma versão pré-modificada da versão 3.97 do LAME que foi utilizada como base para o codificador deste trabalho. O codificador LAME recebe o áudio em formato digital, realiza a eliminação das partes inaudíveis pelo ouvido humano e comprime o áudio restante gerando dados no formato MP3. Com isso, a API da biblioteca do codificador LAME foi utilizada para implementar a codificação do Servidor de Áudio que codifica os dados capturados pelo microfone com a finalidade de diminuir o tempo de envio. Enquando a implementação do LAME em CUDA tem o objetivo de reduzir o tempo da compressão dos dados em inglês, speech codec 5

34 Detalhes da Implementação O cliente e o servidor foram implementados na linguagem C e para as modificações do código da biblioteca LAME foram utilizados C e CUDA. A primeira coisa a ser feita em um ciclo é a configuração do LAME. A cada codificação o LAME deve ser configurado pois algumas variáveis de configuração não podem ser reutilizadas. A geração do áudio é feita através de um microfone configurado pela biblioteca de áudio ALSA que captura o áudio no formato PCM de 16 bits little-endian sinalizado, em apenas um canal, com uma taxa de amostragem de 44100Hz. Para conter o áudio capturado, utiliza-se um buffer implementado em um vetor de elementos do tipo short int (16 bits) com 1152 posições 6. Logo, cada leitura do microfone captura 1152 amostras PCM. Após a captura, o áudio é copiado para a memória da GPU e codificado utilizando uma função de codificação da biblioteca LAME mantendo as mesmas configurações supracitadas. Os dados do áudio codificado retornados pela função são armazenados em um buffer de unsigned char de tamanho definido através de uma função da biblioteca LAME que calcula o tamanho do buffer de acordo com as configurações definidas. Por fim, o buffer MP3 é enviado a um cliente em outra máquina através de um socket que utiliza o protocolo UDP. Do outro lado, o cliente recebe o buffer MP3 e realiza sua descodificação utilizando uma função de descodificação da biblioteca LAME que retorna o áudio em amostras PCM e na seqüência esse áudio é reproduzido através da biblioteca de áudio ALSA Codificação em GPU Para codificar o áudio foram utilizadas funções da biblioteca LAME, foi utilizada a versão 3.97 do LAME disponibilizada pelo concurso da NVidia de implementação do codificador LAME em CUDA. Essa versão do LAME possui uma implementação em CUDA para o filtro passa-alta do modelo psicoacústico e do ajuste de escala de amostra da função de 6 Tamanho do quadro MP3