Hardware/Software co-design para aplicações de processamento de voz

Transcrição

1 Hardware/Software co-design para aplicações de processamento de voz Pedro Manuel Fonseca da Mota (ee00022) Pedro Manuel Vieira dos Santos (ee00115)

2 Hardware/Software co-design para aplicações de processamento de voz - 1 Este projecto foi desenvolvido no âmbito da cadeira de Projecto, Seminário ou Trabalho de fim de curso em parceria com a empresa Chipidea. Pretende-se agradecer a orientação dos responsáveis da Feup, professor João canas Ferreira e professor Aníbal José Ferreira e da empresa Chipidea, em particular aos Engº António Pacheco e Engº Vasco Santos, pela sua preciosa colaboração.

3 Hardware/Software co-design para aplicações de processamento de voz Sumário Introdução O codec de voz AMR Descrição geral Princípios do codificador de voz AMR Princípios do descodificador de voz AMR Detector de presença de voz (VAD) Controlo do débito (SCR) Código C para o codec de voz AMR Conteúdos do código C Execução do programa Estrutura do código Hierarquia do código OpenRISC 1200 RISC/DSP Core Descrição do OpenRISC 1200 Core CPU/DSP Unidade de Instruções Registos para uso genérico (GPR) Unidade de Load/Store Excepções System Unit Pipeline e MAC Unit DSP MAC Caches Memory Management Unit Power Management Unit Unidade de Debug Tick Timer Integrado Programmable Interrupt Controller Unidades Adicionais E Definidas Pelo Utilizador Ferramentas De Suporte Ao Desenvolvimento Sistemas Operativos Suportados: Interface do Sistema Nível de transferência lógica de registos do OR CPU Core top-level Slices associadas ao CPU Core Top-level do OPENRISC Adaptando o Or1k ao espaço disponível Ferramentas de desenvolvimento Ferramentas disponíveis e funcionalidade Instalação das ferramentas Produção de binários e ferramentas auxiliares Simulação dos binários produzidos Funções de interesse presentes na libraria usada no linking Profiling e análise do codec AMR Introdução...70

4 Hardware/Software co-design para aplicações de processamento de voz Análise ao estilo de programação definido pela norma Operações básicas Uso do ficheiro count.c para realizar o profiling do codec Profiling do codec AMR Optimização do algoritmo pesquisa do codebook inovativo no modo 12.2 kbit/s Medição das operações básicas no codec Pequeno programa a simular no processador lei A Introdução A lei A Implementação da lei A no processador O caminho para a implementação do Or1k em hardware Plataforma de desenvolvimento Comunicação entre a memória e o Or1k Controlador de Memórias Área ocupada pelo controlador de memórias Configuração do controlador de memórias Aceder aos registos de configuração e ao espaço de memória Testbench do controlador de memórias Descrição das unidades auxiliares para teste Testes pretendidos para o modelo desenvolvido e concretização Formas de onda obtidas e o protocolo wishbone Or1k e memory controller: necessidade de um arbitrador Testbench para o sistema master/slave Adaptação da norma do codec AMR à arquitectura do processador OpenRISC Definição dos tipos de variáveis no OpenRISC Funções não reconhecidas pelo compilador do OpenRISC Optimização das operações básicas no OpenRISC Escrita de instruções assembly em código C Colocação das operações básicas inline O uso de macros mas operações básicas Alteração do código nas funções básicas As flags de Overflow e Carry Instruções de adição/subtracção Instruções de multiplicação Instruções de normalização Instruções shift left/right Instruções mac Outras instruções Problemas encontrados Problemas do compilador Melhorias observadas pelo uso das macros Perspectivas de desenvolvimento futuras Operações básicas a serem implementadas na arquitectura do OPENRISC bits versus 16 bits Conclusões Bibliografia

5 Hardware/Software co-design para aplicações de processamento de voz - 4 Lista de Figuras Figura 1: Funções gerais do processamento de áudio do codec AMR...13 Figura 2: Diagrama de blocos simplificado do modelo de síntese de voz CELP...14 Figura 3: Diagrama de blocos simplificado do codificador de voz AMR...17 Figura 4: Diagrama de blocos simplificado do descodificador de voz AMR Figura 5: Diagrama de blocos simplificado do algoritmo VAD Figura 6: Diagrama de blocos de uma ligação com operação SCR...21 Figura 7 - OpenRISC 1200 Core...31 Figura 8 - Blocos que constituem o CPU/DSP Core...33 Figura 9: Estrutura da cache...36 Figura 10 CvsGet da página Figura 11: Esquema que representa o Core do CPU...42 Figura 12: Organização do top-level do Or1k (slices ocupadas por cada módulo)...45 Figura 13: Configuração do OpenRisc 1200 no seu top-level e interface com o exterior...49 Figura 14: Resultados obtidos ao ser invocado o or32-uclinux-objdump S mul...58 Figura 15:Resultados obtidos ao ser invocado o or32-uclinux-readelf a mul...60 Figura 16: Resultados da execução do comando or32-uclinux-readelf x 1 mul...60 Figura 17:Resultados obtidos ao ser invocado o or32-uclinux-size -- radix=16 mul ( formatação em hexadecimal)...61 Figura 18: Configuração da memória usada no simulador...65 Figura 19:Resultado da execução do programa de teste mul...67 Figura 20: Resultado da simulação do ficheiro representado acima...69 Figura 21: Interface necessário para realizar a comunicação com a memória da Cypress...84 Figura 22: Modelo pretendido em relação ao controlador de memórias...85 Figura 23:Arquitectura do controlador de memórias...86 Figura 24:Registos de configuração presentes no controlador de memórias...90 Figura 25:Modelo usado no testbench...92 Figura 26: Modo de geração dos endereços quando se realizam bursts...94 Figura 27: Timings e formas de onda associados à leitura da memória da Micron...94 Figura 28:Timings e formas de onda que estão associados à memória da Micron...95 Figura 29: Programação da mascara para o base address e do control status register...96 Figura 30:Configuração do CSC register e TMS register...96 Figura 31: Resultado da execução do testbench default relativo ao memory controller...97 Figura 32: Formas de onda associadas à escrita/leitura usando o protocolo wishbone...99 Figura 33:Descrição dos sinais de wishbone Figura 34: Memória instanciada no sistema Figura 35: Resultado da simulação em relação aos sinais da SSRAM Figura 36: Modificação para fazer uso da memória da Cypress Figura 37: Forma de ondas obtidas com a memória da Cypress Figura 38 Configuração do Wishbone builder Figura 39: Modelo Master Model para teste Figura 40 : Teste do master model com acessos alternados Figura 41: Resultados da execução do testbench com acesso concorrente dos...107

6 Hardware/Software co-design para aplicações de processamento de voz - 5

7 Hardware/Software co-design para aplicações de processamento de voz - 6 Lista de Tabelas Tabela 1: Alocação de bits do algoritmo do codec AMR para uma frame de 20 ms...18 Tabela 2: Estruturas existentes no codificador de voz AMR Tabela 3: Estruturas existentes no descodificador de voz AMR...27 Tabela 4: Estrutura da chamada das funções do codificador...28 Tabela 5: Estrutura da chamada das funções da função cbsearch Tabela 6: Estrutura da chamada das funções da função gainquant Tabela 7: Estrutura da chamada das funções do descodificador Tabela 8: Macros e respectiva interferência no sistema...40 Tabela 9: Módulos presentes no CPU Core, correspondência com ficheiro e respectiva funcionalidade...43 Tabela 10: Ficheiro e funcionalidade correspondentes para um determinado módulo do Or1k...46 Tabela 11: Slices ocupadas por cada uma das memórias...49 Tabela 12:Comandos disponíveis no simulador e respectiva funcionalidade...64 Tabela 13: Secções que constituem o sim.cfg e que podem sofrer alterações...67 Tabela 14: Operações básicas usadas pela norma do codec AMR...72 Tabela 15: Peso computacional do codec AMR em WMOPS (weighted million operations per second)...74 Tabela 16: Peso computacional do codificador de voz AMR no modo 12.2 kbit/s em WMOPS Tabela 17: Peso computacional do descodificador de voz AMR no modo 12.2 kbit/s em WMOPS Tabela 18: Posições potenciais dos pulsos individuais no codebook algébrico para o modo 12.2 kbit/s Tabela 19: Número de ocorrências médias das operações básicas do codec no modo 12.2 kbit/s por frame Tabela 20: Codificação definida pela lei A Tabela 21: Configuração do Chip select register para uma memória SSRAM...88 Tabela 22: Lista de sinais associados ao protocolo wishbone e respectiva funcionalidade (obtidos a partir do documento de wishbone)...98 Tabela 23: Número de instruções obtido da simulação para o codificador e descodificador.126 Tabela 24: MIPS médio para codificador e descodificador...126

8 Hardware/Software co-design para aplicações de processamento de voz - 7 Ficheiros de Apoio Ficheiro de apoio 1: default.ld- contém as definições das diversas regiões de memória e endereços iniciais...55 Ficheiro de apoio 2:Makefile que permite a criação do binário a ser usado para a simulação.56 Ficheiro de apoio 3: Aspecto do simulador. São evidenciados os registos e as instruções do processador Ficheiro de apoio 4: Ficheiro que mostra a potencialidade das funções referidas...69

9 Hardware/Software co-design para aplicações de processamento de voz - 8 Anexos Anexo 1:Versão simplificada do algoritmo do codificador ficheiro s10_8pf.c Anexo 2:Contagem das operações básicas da norma do codec ficheiro count.c Anexo 3: Implementação da lei A em código C Anexo 4:Top level do CPU Anexo 5: Instruções de vírgula fixa do processador Or1k Anexo 6: Funções básicas da norma do codec implementadas em asssembly Anexo 7: tt_ssram.v Anexo 8: bench.v Anexo 9: wb.vhd (descrição do master slave) Anexo 10: Wishone.defines (definições para a elaboração do master slave) Anexo 11: Modelo verilog da memória da Cypress Anexo 12: Modelo verilog da memória da Micron Anexo 13: bench1.v Anexo 14: bench2.v Anexo 15: Or1k TOP level Anexo 16: mc_defines.v Anexo 17 : Top level do master slave...219

10 Hardware/Software co-design para aplicações de processamento de voz Sumário A sociedade moderna assenta a sua dinâmica nas telecomunicações e contacto em tempo real. Por essa razão vários sistemas capazes de realizar a codificação de voz têm sido desenvolvidos. Integrado no contexto mencionado, neste projecto pretende-se realizar a implementação de um codificador de voz de débito variável, usando um processador dedicado. A linha orientadora assenta sobre a optimização quer a nível de software, a que corresponde a modificação de algoritmos, quer a nível de hardware, onde a arquitectura do processador é refinada para a aplicação desenvolvida. Este codec tem a capacidade de baixar ou aumentar o seu débito mediante as maiores ou menores interferências no canal de comunicação. Nas condições referidas, a codificação de canal contra erros será maior no caso de interferências mais acentuadas, garantindo-se assim que o bom desempenho do codec seja mantido. A arquitectura do processador usado é de domínio público, tendo sido desenhada com o objectivo de implementar um sistema capaz de ter consumo de potência reduzido, simplicidade, versatilidade e reduzida área. A avaliação das vantagens e desvantagens da utilização do modelo open-source no desenvolvimento de sistemas electrónicos dedicados é um dos motivos nucleares.

11 Hardware/Software co-design para aplicações de processamento de voz Introdução Neste projecto pretendeu-se realizar a implementação da norma 3GPP TS V6.0.0 de codificação de audio para UMTS usando o processador OpenRisc A arquitectura do processador OpenRISC 1200 é de domínio público, constituindo a base para as famílias de processadores do tipo RISC/DSP de 32-bit e 64-bit. Este codec foi escolhido pela Third Generation Partnership Project (3GPP) como o codec principal para os sistemas da 3ª geração. A filosofia por detrás do AMR é baixar o seu débito assim que as interferências aumentem, possibilitando desta forma uma maior ou menor codificação de canal contra erros. Neste trabalho fez-se o estudo do OR1k, relativamente ao nível de tranferência lógica de registos, verificando qual era a sua caracterização em termos de performance, velocidade e área relativamente a um conjunto de módulos que lhe estavam associados. Essa caracterização é de tal forma importante, que sem a mesma, não se poderia adaptar este processador para a plataforma de desenvolvimento. Na parte do codec, fez-se um profiling das funções que ocupam mais processamento e implementou-se uma modificação no sentido de realizar optimizações a nível computacional com resultados comprovados. Numa outra fase, dedicaram-se os esforços para conseguir ter as ferramentas orientadas a este processador em funcionamento. Fizeram-se testes de pequenos segmentos de código e com base neles compreendeu-se a forma de poder interagir com o compilador e simulador, disponíveis de forma livre. Um teste mais profundo foi a implementação da lei A, onde na parte de software se fizeram as alterações necessárias à implementação do mesmo na arquitectura deste mesmo processador. Por outro lado, observou-se como funcionava a memória deste processador, registos e o assembly gerado com base no código C. A fase que mais recursos consumiu constitui a adaptação do código desta norma para a arquitectura do processador, onde diversas modificações tiveram de ser implementadas. Por outro lado foi necessário integrar o OR1k no sistema oferecido pela plataforma de desenvolvimento, tendo-se encontrado aí dificuldades.

12 Hardware/Software co-design para aplicações de processamento de voz - 11 Após ter sido terminada a adaptação da norma para a arquitectura, procedeu-se à sua caracterização em termos de instruções executadas no simulador, verificando-se que de facto uma variedade de optimizações podia ser implementada. Essas optimizações passaram pela escrita de funções em assembly, revelando-se uma solução poderosa. A integração do or1k continua, passando pela introdução de um controlador de memória, um master/slave capaz de estabelecer prioridades nos barramentos de dados, até chegar a um modelo final em que o core do OR1k tem acesso à memoria presente na plataforma de desenvolvimento. A optimização da norma revelou ser de facto espantosa em termos do número de instruções agora necessárias, cerca de 2,3 x menos existindo um caminho disponível para melhorar ainda mais este valor. No caso de hardware, o teste de um modelo capaz de verificar se o sistema integrado do or1k, master/slave e memory controller é capaz de funcionar e correr um programa compilado para este processador, foi a ultima tarefa que se pretendeu cumprir.

13 Hardware/Software co-design para aplicações de processamento de voz O codec de voz AMR 3.1 Descrição geral Desenvolvido pela European Telecommunications Standards Institute (ETSI) e standardizado para GSM, este codec foi escolhido pela Third Generation Partnership Project (3GPP) como o codec principal para os sistemas da 3ª geração. A filosofia por detrás do AMR é baixar o seu débito assim que as interferências aumentem, possibilitando desta forma uma maior ou menor codificação de canal contra erros. O AMR também é usado para harmonizar standards entre diferentes sistemas de telecomunicações celulares. O codec de voz AMR consiste assim num codificador de voz de débitos múltiplos, um esquema capaz de controlar e gerir os diferentes débitos através dum detector de presença de voz e um gerador de ruído de conforto, e um mecanismo de cancelamento de erros para combater os efeitos provocados por erros de transmissão. Este codec integra oito diferentes débitos desde 4.75 kbit/s a 12.2 kbit/s para codificar voz propriamente dita e um modo de baixo débito para codificar ruído de fundo. O codificador de voz é capaz de variar o seu débito a cada frame de 20ms. Toda a descrição detalhada deste codec pode ser encontrada no site da 3GPP em Aqui podem ser encontrados todos os documentos que descrevem esta norma em todas as suas vertentes. Na figura seguinte é possível ver-se aquilo que foi descrito anteriormente. Note-se que a fonte do sinal a ser codificada tem que surgir no formato PCM de 13 bits. Caso o sinal de entrada esteja codificado de acordo com a lei A, este terá que ser convertido para PCM de forma a ser codificado correctamente.

14 Hardware/Software co-design para aplicações de processamento de voz - 13 GSM AMR GSM AMR BSS side only GSM AMR Voice Activity Detector 3 1 8bit / A-law to 13-bit uniform LPF A/D 2 Speech Encoder VAD GSM AMR 6 4 Speech frame DTX Control and Operation SP flag 6 7 MS side only TRANSMIT SIDE GSM Comfort Noise TX Functions GSM AMR 5 SID frame Info. bits GSM AMR GSM AMR Info. bits 8 Speech frame substitution BSS side only GSM AMR BFI 9 GSM AMR 13-bit uniform to 8bit / A-law 1 SID 10 DTX Control and Operation 4 Speech Decoder 2 TAF Speech frame D/A LPF 11 GSM AMR 5 SID frame Comfort Noise RX Functions MS side only RECEIVE SIDE GSM Figura 1: Funções gerais do processamento de áudio do codec AMR. 1) 8-bit A-law or µ-law PCM (ITU-T Recommendation G.711), samples/s; 2) 13-bit uniform PCM, samples/s; 3) Voice Activity Detector (VAD) flag; 4) Encoded speech frame, 50 frames/s, number of bits/frame depending on the AMR codec mode; 5) SIlence Descriptor (SID) frame; 6) TX_TYPE, 2 bits, indicates whether information bits are available and if they are speech or SID information;

15 Hardware/Software co-design para aplicações de processamento de voz ) Information bits delivered to the 3G AN; 8) Information bits received from the 3G AN; 9) RX_TYPE, the type of frame received quantized into three bits. 3.2 Princípios do codificador de voz AMR O codec AMR consiste em oito diferentes fontes de débitos: 12.2, 10.2, 7.95, 7.40, 6.70, 5.90, 5.15 e 4.75 kbit/s. Este codec é baseado no modelo CELP (code-excited linear predictive). É usado um filtro de síntese obtido por uma análise de 10ª ordem dos parâmetros de predição linear, dados pela seguinte formúla: 1 1 Hz ( ) = Az $ = ( ) m 1+ az $ i = 1 onde â i são os parâmetros LP quantizados e m = 10 é a ordem de predição. A síntese de pitch é feita recorrendo-se ao seguinte filtro: 1 1 = Bz ( ) 1 g z onde T é o atraso do pitch e g p o seu ganho. Este filtro é implementado usando técnicas adaptativas. p T i i O modelo de síntese deste codec de voz é ilustrado na figura seguinte: adaptive codebook g p v(n) fixed codebook + u(n) 1 s(n) ^ A(z) post-filtering s'(n) ^ g c c(n) LP synthesis Figura 2: Diagrama de blocos simplificado do modelo de síntese de voz CELP.

16 Hardware/Software co-design para aplicações de processamento de voz - 15 Neste modelo, o sinal de excitação à entrada do filtro de síntese LP é construído adicionando-se dois vectores de excitação: um do codebook fixo e outro do codebook adaptativo. O sinal de fala é sintetizado fazendo-se passar pelo filtro LP o sinal proveniente da soma dos codebooks. O sinal de excitação óptimo é obtido fazendo-se uma análise por síntese onde o erro entre o sinal original e o sintetizado é minimizado de acordo com uma medida de distorção pesada perceptual. O filtro de distorção perceptual usado na técnica de análise por síntese é dado por: Az Wz ( ) = Az ( γ 1) ( γ ) onde A(z) é o filtro LP não quantizado e 0 < γ 2 <γ 1 1 são os pesos dos factores perceptuais. Valores de γ 1 = 0.9 (para os modos de 12.2 e 10.2 kbit/s) ou γ 1 = 0.94 (para os restantes modos) e γ 2 = 0.6 são usados. O codificador opera com frames de fala de 20 ms cada, correspondendo a 160 amostras obtidas a um frequência de amostragem de 8000 amostras por segundo. A cada 160 amostras, o sinal é analisado de forma a extrair os parâmetros do modelo CELP: coeficientes do filtro LP, índices e ganhos dos codebooks adaptativo e fixo. Estes parâmetros são codificados e transmitidos. No descodificador, estes parâmetros são descodificados e o sinal de fala é sintetizado fazendo-se passar o sinal de excitação (codebook adaptativo mais codebook fixo) pelo filtro de síntese LP. No diagrama seguinte ilustra-se todas as operações realizadas pelo codificador. Análise LP é realizada duas vezes por frame para o modo de 12.2 kbit/s e uma vez para os restantes modos. Para o modo 12.2 kbit/s, dois conjuntos de parâmetros LP são convertidos para line spectral pairs (LSP) e quantizados juntamente usando split matrix quantization (SMQ) num total de 38 bits. Para os outros modos, é feita uma análise LP que é convertida para LSP e quantizada usando split vector quantization (SVQ). A frame do sinal de fala é dividida em 4 subframes de 5 ms cada (40 amostras). Os parâmetros do codebook fixo e adaptativo são transmitidos em cada subframe. Os parâmetros LP quantizados e não quantizados ou suas versões interpoladas são usadas dependendo da subframe. Um atraso de pitch é estimado em open-loop em cada 2

17 Hardware/Software co-design para aplicações de processamento de voz - 16 subframe (excepto para os modos 5.15 e 4.75 kbit/s onde é feito uma vez por frame) baseado no sinal de fala perceptualmente pesado. De seguida as seguintes operações são repetidas para cada subframe: O sinal objectivo x(n) é calculado filtrando o sinal residual LP através do filtro de síntese pesado W(z)H(z) com o estado inicial dos filtros sendo actualizados pela filtragem do erro entre o LP residual e a excitação (isto é equivalente a subtrair a resposta do filtro de síntese pesado a uma entrada nula ao sinal de fala pesado). A resposta impulsional, h(n) do filtro de síntese pesado é calculada; Uma análise, dita closed-loop, do pitch é realizada (para encontrar o atraso e ganho do pitch), usando o sinal objectivo x(n) e a resposta impulsional h(n), pesquisando em torno do atraso obtido no open-loop pitch. Pitch fraccionários com 1/6 ou 1/3 de resolução de uma amostra (dependendo de modo) são usados; O sina objectico x(n) é actualizado removendo-se a contribuição do codebook adaptativo, e este novo sinal objectivo, x2(n), é usado na pesquisa do codebook algébrico (inovativo), por forma a encontrar o melhor codebook; Os ganhos do codebook adaptativo e inovativo são quantificados escalarmente com 4 e 5 bits respectivamente ou quantificados com 6 ou 7 bits (com predição do movimento da média aplicada ao ganho do codebook fixo); Finalmente, as memórias dos filtros são actualizadas (usando o sinal de excitação determinado) para encontrar o sinal na próxima subframe.

18 Hardware/Software co-design para aplicações de processamento de voz 17 Pre-processing Pre-processing windowing and autocorrelation R[ ] Levinson- Durbin R[ ] A(z) A(z) LSP LSP indices LSP quantization interpolation for the 4 subframes LSP A(z) ^ frame subframe LPC analysis (twice per frame) Open-loop pitch search Adaptive codebook (twice per frame) search Innovative codebook search s(n) interpolation for the 4 subframes LSP A(z) A(z) compute weighted speech (4 subframes) find open-loop pitch A(z) ^ A(z) compute target for adaptive codebook x(n) T o find best delay and gain h(n) quantize LTP-gain compute adaptive codebook contribution x(n) pitch index LTP gain index compute target for innovation x (n) 2 find best innovation code index A(z) ^ A(z) compute impulse response h(n) Filter memory update update filter memories for next subframe compute excitation fixed codebook gain quantization fixed codebook gain index Figura 3: Diagrama de blocos simplificado do codificador de voz AMR. A alocação de bits para o codec AMR nos seus diferentes modos é mostrada na tabela seguinte. Em cada 20 ms de sinal de fala, 95, 103, 118, 134, 148, 159, 204 ou 244

19 Hardware/Software co-design para aplicações de processamento de voz 18 bits são produzidos, correspondendo aos débitos de 4.75, 5.15, 5.90, 6.70, 7.40, 7.95, 10.2 ou kbit/s. Mode Parameter 1st subframe 2nd subframe 3rd subframe 4th subframe total per frame 2 LSP sets kbit/s Pitch delay (GSM EFR) Pitch gain Algebraic code Codebook gain Total 244 LSP set kbit/s Pitch delay Algebraic code Gains Total 204 LSP sets kbit/s Pitch delay Pitch gain Algebraic code Codebook gain Total 159 LSP set kbit/s Pitch delay (TDMA EFR) Algebraic code Gains Total 148 LSP set kbit/s Pitch delay (PDC EFR) Algebraic code Gains Total 134 LSP set kbit/s Pitch delay Algebraic code Gains Total 118 LSP set kbit/s Pitch delay Algebraic code Gains Total 103 LSP set kbit/s Pitch delay Algebraic code Gains Total 95 Tabela 1: Alocação de bits do algoritmo do codec AMR para uma frame de 20 ms. 3.3 Princípios do descodificador de voz AMR No diagrama da figura seguinte é ilustrado o processo de descodificação e síntese dum sinal de fala produzido pelo descodificador AMR.

20 Hardware/Software co-design para aplicações de processamento de voz 19 frame subframe post-processing LSP indices decode LSP interpolation of LSP for the 4 subframes pitch index gains indices code index decode adaptive codebook decode innovative codebook decode gains construct excitation synthesis filter s(n) ^ post filter ^ s'(n) LSP ^ A(z) Figura 4: Diagrama de blocos simplificado do descodificador de voz AMR. Aqui, dependendo do modo escolhido, os índices transmitidos são extraídos do bitstream recebido. Estes índices são descodificados para obter os parâmetros de codificação a cada frame transmitida. Os parâmetros são os vectores LSP, os atrasos fraccionários do pitch, o codebook inovativo e os ganhos do pitch e codebook inovativo. Os vectores LSP são convertidos nos coeficientes do filtro LP e interpolados para obter filtros LP em cada subframe. Então, a cada 40 amostras (subframe) é realizado o seguinte: A excitação é construída por adição do codebook inovativo e adaptativo escalados dos seus respectivos ganhos; O sinal de fala é reconstruído por filtragem da excitação através do filtro de síntese LP. Finalmente, o sinal de fala reconstruído é filtrado por uma pós-filtragem adaptativa. 3.4 Detector de presença de voz (VAD) O algoritmo VAD (voice activity detector) usa os parâmetros do codificador de voz para calcular uma flag que simplesmente indique a presença ou não de um sinal de voz.

21 Hardware/Software co-design para aplicações de processamento de voz 20 No esquema seguinte pode-se ver um diagrama de blocos representativo deste algoritmo. s(i) Filter bank and computation of sub-band levels level[n] T_op[n] Pitch detection pitch tone VAD decision VAD_flag t0,t1 Tone detection complex_warning OL-LTP correlation vector Complex signal analysis complex_timer Figura 5: Diagrama de blocos simplificado do algoritmo VAD. Amostras da frame de entrada, s(i), são divididas em sub-bandas e o nível do sinal para cada sub-banda é então calculado. A entrada do bloco de detecção de pitch, T_op[n], é o resultado do atraso do pitch calculado no codificador de voz. Este bloco calcula uma flag (pitch) que indica a presença ou não de pitch. O bloco de detecção de tom calcula uma flag (tone), que indica a presença de um tom de informação. Tons são detectados tendo como base o ganho de pitch obtido na análise em open-loop pelo codificador de voz. A detecção de sinais complexos calcula uma flag (complex_warning), indicando a presença de sinais complexos como, por exemplo, música. Esta detecção é feita tendo como base o vector de correlação disponível na análise em open-loop do pitch. A função de decisão de VAD estima níveis de ruído de fundo. Estes níveis são comparados com os níveis da frame de entrada (level[n]) por forma a tomar-se uma decisão intermédia. Finalmente, a decisão final é tomada tendo em consideração decisões tomadas anteriormente.

22 Hardware/Software co-design para aplicações de processamento de voz Controlo do débito (SCR) A operação SCR (source controlled rate) é o mecanismo que permite a um codificador de voz AMR codificar com um débito médio inferior, tendo em conta os períodos de inactividade de voz. Este esquema é particularmente útil para se poder poupar energia nos equipamentos terminais, uma vez que quando não há actividade de voz, o processamento sobre o sinal fica simplificado para reduzir cargas de débitos a que as redes de comunicações ficam sujeitas. Esta operação requer do lado do emissor um detector de voz e um avaliador do ruído de fundo a ser transmitido. Do lado de receptor terá que existir um gerador de ruído de fundo (ruído de conforto), durante os períodos onde a transmissão está desligada. No esquema seguinte pode ver-se uma ligação entre emissor e receptor usando uma operação SCR. TX SCR handler Network RX SCR handler Speech Encoder Voice Activity Detector Comfort Noise Parameter Computation Information bits Mode Indication TX_TYPE Information packeting, transport and classification Information bits Mode Indication RX_TYPE Figura 6: Diagrama de blocos de uma ligação com operação SCR. Speech Decoder Error Concealment Comfort Noise Generation De notar que, em adição a estas funcionalidades, se os parâmetros chegados ao receptor forem detectados como estando seriamente corrompidos por erros, o sinal de fala ou de ruído de conforto deve ser substituído por outros dados de forma a evitar efeitos desagradáveis para o ouvinte. 3.6 Código C para o codec de voz AMR Esta é a parte da norma que engloba as diferentes componentes que constituem o codec AMR. Aqui, foi realizada uma implementação em vírgula fixa das funções que codificam a voz, o detector de presença de voz, ruído de conforto, controlo de débito e substituição de frames perdidas.