Quando considerar o ponto flutuante duplo (64 bits) para Áudio


12

Ao sintetizar e processar áudio em processadores modernos, quando alguém consideraria usar algo diferente de ponto flutuante de precisão única (32 bits)? Obviamente, o áudio que entra e sai do mundo real é de 16/24 bits, então estou falando da precisão dos sinais (tanto do próprio áudio quanto de coeficientes de filtro) no software.

Assuma isso:

  • a CPU / DSP possui suporte a ponto flutuante de hardware para precisão única e dupla
  • A prioridade é a qualidade do áudio, não o alto desempenho. Por exemplo, a precisão dupla seria considerada se oferecesse melhor qualidade (perceptual).

Respostas:


9

Os singles float IEEE fornecem apenas cerca de 24 bits de mantissa. Mas muitos algoritmos DSP / filtragem (biqueiras IIR com pólos / zeros próximos ao círculo unitário, etc.) exigem muito mais do que 24 bits de mantissa para produtos computacionais intermediários (acumuladores, etc.), apenas para obter resultados finais precisos para perto de 16 ou 24 bits. Para esses tipos de algoritmos, acumuladores inteiros em escala de 32, 40 e 48 bits eram frequentemente usados ​​com DSPs que não tinham FPU.

Porém, em muitas implementações atuais de processadores (para PCs, smartphones etc.), a FPU de precisão dupla é muito mais rápida do que tentar usar números inteiros em escala de 32 ou 64 bits quando seu algoritmo precisa ter mais de 24 bits de produto intermediário.

Para evitar que o cache de dados seja destruído, os dados brutos podem estar no formato inteiro flutuante de precisão inteira ou única, enquanto apenas o kernel computacional mais local pode usar um formato de resolução mais alta. Mas se você estiver compartilhando resultados intermediários de computação entre os módulos DSP, o protocolo de intercâmbio entre os módulos também poderá se beneficiar de um formato de barramento ou de dados de resolução mais alta (mais de 24 bits mantissa).


Esse é o tipo de informação que eu procurava. Aceitarei esta resposta se você poderia gentilmente fornecer um exemplo concreto de um caso em que é necessária dupla precisão para fazer um filtro funcionar, ou seja, parecerá ruim (ou pelo menos bastante comum) com precisão única, mas suave como manteiga com dupla precisão.
user1849104

Além disso, o que exatamente você quer dizer com lixeira no cache? Você quer dizer que ter o dobro de dados passando por eles tornará as coisas terrivelmente lentas?
user1849104

Um exemplo foi dado, IIR com pólos / zeros perto do círculo unitário. Se houver um cache, algoritmos e conjuntos de dados de trabalho que se encaixam nesse cache podem ser significativamente mais rápidos do que aqueles que não o fazem.
hotpaw2

9

a CPU / DSP possui suporte a ponto flutuante de hardware para precisão única e dupla.

Realmente depende de que tipo de suporte você está falando. No x86, ao usar as instruções de ponto flutuante no estilo x87, você obtém a precisão interna total de 80 bits e o mesmo tempo de processamento - esteja trabalhando com precisão única ou dupla.

Porém, ao usar as instruções SIMD, você pode realizar o trabalho duas vezes mais usando flutuadores de 32 bits do que flutuadores de 64 bits. Isso é grande coisa.

Outra coisa a considerar é a memória - o uso de dupla precisão divide por dois a quantidade de dados que se encaixa nos níveis mais rápidos de memória cache.

Ao sintetizar e processar áudio em processadores modernos,

Tudo se resume a que tipo de síntese e processamento você faz. Se envolver filtros IIR (ou, geralmente, qualquer coisa com variáveis ​​de estado e / ou feedback), você poderá disparar com mais facilidade no pé (instabilidades ou imprecisões de corte baixo devido ao truncamento coeficiente) com 32 bits, se não o fizer pense demais no que está fazendo. Algumas topologias de filtro funcionam perfeitamente com 32 bits.

De qualquer forma, é uma questão de precisão numérica - em termos de qualidade, não haverá diferença perceptiva. Lembre-se de que é bastante ridículo esperar que uma cadeia de áudio de hardware tenha mais de 20 bits de precisão (supondo que a placa seja roteada impecavelmente e que todas as peças sejam ideais, ainda estamos correndo para o limite do ruído da Johnson!) - e essa precisão é amplamente coberta por flutuadores de precisão única. O caminho do sinal em uma mesa de mistura sofisticada possui 50s de amplificadores operacionais, que individualmente possuem várias ordens de magnitude mais distorção do que o ruído de quantização de operações aritméticas em flutuadores de precisão única.


Seria seguro dizer que o uso de precisão única com instruções SIMD sempre fornecerá aproximadamente o dobro do desempenho em relação à precisão dupla?
user1849104

Como não consigo mais editar o comentário anterior: nunca tive a oportunidade de (diretamente) usar nenhum conjunto de instruções SIMD. É possível simplesmente usar precisão única e obter o dobro do desempenho? Ou a realidade atrapalha?
user1849104

6

Você precisa conhecer os requisitos numéricos do seu algoritmo e escolher a precisão de acordo.

Então, vamos fazer as contas aqui: um ponto flutuante de 32 bits tem uma mantissa de 24 bits e um expoente de 8 bits. Isso fornece uma relação sinal / ruído de cerca de 150 dB em uma faixa dinâmica de cerca de 1540 dB. Isso é suficiente para a maioria das coisas em áudio. A precisão dupla oferece aproximadamente o dobro.

Cada algoritmo possui certos requisitos para precisão numérica. Se projetado adequadamente, todos os algoritmos de áudio que eu conheço fazem muito bem com o ponto flutuante de 32 bits. "projetado corretamente" é a palavra-chave aqui. Por exemplo, uma passagem de banda de 6ª ordem de 40-200 Hz amostrada em 44,1kHz implementada como filtro direto do II IIR bi-quad terá de fato alguns problemas de ruído em 32 bits. No entanto, funciona perfeitamente bem como forma transposta II ou forma direta I filtrada.

Se você tentar uma expansão de fração parcial do mesmo filtro de passagem de banda usando, por exemplo, a função residuez () do Matlab, obterá resultados ruins, mesmo com precisão dupla. Novamente, os requisitos numéricos do algoritmo para esses dados de entrada específicos excedem o que a precisão dupla tem a oferecer. A chave para corrigir isso não é aumentar cegamente a precisão, mas usar um algoritmo melhor.

Finalmente, vamos dar uma olhada no que torna a flutuação (32 bits ou 64 bits) vulnerável: você tem uma enorme faixa dinâmica, ou seja, você pode reduzir o sinal em 200dB, amplificar em 500dB, reduzir novamente em 300dB e terminar exatamente onde começou com quase nenhuma perda de precisão. Então não é isso. O ponto flutuante tem problemas para adicionar números de tamanho muito diferente. Há um ponto em que adicionar um número pequeno simplesmente não faz diferença, ou seja, você recebe 1 + dx = 1. Esse número "dx" é de cerca de 1,2e-7 para ponto flutuante de 32 bits e 2,2e-16 para 64 bits. Se o seu algoritmo incluir adicionar ou subtrair números tão distantes em magnitude, você poderá encontrar problemas.

Um bom exemplo disso é o filtro Direct Form II mencionado anteriormente: O filtro direto From II (consulte, por exemplo, https://ccrma.stanford.edu/~jos/fp/Direct_Form_II.html ) basicamente calcula as variáveis ​​de estado filtrando a entrada com a função de transferência somente de polo primeiro e depois filtrando com os zeros para criar a saída. Agora, se os polos estiverem próximos do círculo unitário, a função de transferência somente de polos fica muito, muito grande. Portanto, a variável de estado pode ser muito maior que a entrada (80db a 100dB maior) e a soma de variáveis ​​de estado com a entrada cria muito ruído.

A solução aqui é ir para um filtro de Formulário II transposto ou Formulário I direto. A análise mostra que as variáveis ​​de estado não podem ser maiores que a entrada / saída, talvez 12dB ou aproximadamente, portanto a incompatibilidade de magnitude do problema não ocorre em primeiro lugar.


2

Existem dois benefícios em duplicar a precisão em relação à precisão única: maior alcance e melhor resolução. Eu ficaria muito surpreso se o aumento do alcance fizesse alguma diferença na sua aplicação. Se isso acontecer, provavelmente há algo errado com o seu dimensionamento.

Se houver uma melhoria, estaria na resolução. Melhor resolução significa menos ruído de quantização . A menos que o ruído de quantização esteja próximo do mesmo nível de todas as outras fontes de ruído, provavelmente não fará diferença. Você pode fazer uma análise dos níveis de ruído e sinal para ter uma idéia de quanto do ruído provém do erro de quantização, mas não saberá ao certo se isso fará diferença ou não até que você o implemente com ambos e veja se isso faz diferença.


2

Se você estiver trabalhando com áudio sintetizado que passa por muito processamento entre geração e renderização (conversão para número inteiro de 16/24 bits), será beneficiado por trabalhar com a melhor precisão numérica que sua máquina possui.

Também é importante fazer uma distinção fundamental entre números inteiros e números de ponto flutuante. Um ponto flutuante de precisão dupla (64 bits) é diferente de um número inteiro de 64 bits e você pode trabalhar com números inteiros de precisão arbitrária no software, dependendo das ferramentas de software utilizadas. Isso seria importante se você tivesse que gravar sons em vez de gerá-los (até onde eu sei, a conversão do AD sempre salva os sons amostrados no formato inteiro).

Não tenho muita certeza, mas se você gerar seu som já em ponto flutuante, os artefatos mais comuns provavelmente não estarão presentes por definição, e você poderá processá-lo com muito mais "qualidade de áudio". Talvez você possa gerar as amostras de som apenas APÓS a aplicação de alguns efeitos no próprio gerador. O único momento em que você realmente introduzirá qualquer artefato em potencial é convertê-lo para saída em algum formato de arquivo inteiro, como .WAV, por exemplo.

Na verdade, como a maioria das máquinas tem uma precisão "dupla" (64 bits) nativa hoje em dia, não vejo mais motivo para trabalhar com 32 bits ...

Espero que ajude!


3
"Não vejo mais motivo para trabalhar com 32 bits ...", a menos que você use o SIMD!
Pichenettes
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.