Desempenho de um sintetizador C++ e JUCE sem reduzir vozes ou qualidade

Olá a todos.

Estou desenvolvendo um sintetizador chamado TITAN com C++ e JUCE. Preciso de orientação para diagnosticar seu desempenho sem reduzir vozes, camadas de uníssono nem qualidade sonora.

Esta consulta foi redigida com ajuda de IA. Os números procedem de testes locais.

Configuração:

• Intel Core i5-1155G7, Windows de 64 bits.
• JUCE 7.0.12, compilação Release com MSVC e otimização PGO.
• Áudio a 48 kHz e blocos de 480 amostras: equivalem a 10 ms de áudio.
• Três notas simultâneas, com oito camadas internas de uníssono por nota.
• 800 blocos por execução, incluindo ataque, som sustentado, liberação e silêncio posterior.

Um esclarecimento importante: estamos medindo a chamada completa de processamento mediante um teste offline, sem interface e marcada como não-realtime. Portanto, superar 10 ms aqui não demonstra por si só um corte de áudio ao vivo.

Nas últimas três rodadas comparativas obtivemos estes tempos, em milissegundos:

• Base atual: P95 de 12,09 / 11,94 / 12,33; máximos de 33,18 / 24,07 / 20,36.
• Candidato otimizado: P95 de 12,76 / 11,82 / 10,97; máximos de 78,62 / 21,88 / 36,99.

Os números estão na mesma ordem de rodadas. P95 significa que 95 % das chamadas levaram esse tempo ou menos. Conservamos todos os blocos e picos, sem eliminá-los das estatísticas.

Testamos duas otimizações SIMD independentes. Mantiveram exatamente o áudio e os estados comparados, mas nenhuma melhorou consistentemente o bloco completo. Ficaram descartadas.

Minhas perguntas são:

1. Como fariam um teste representativo do processamento em tempo real para contrastá-lo com esta medição offline?
2. Como separariam o tempo de cálculo DSP do tempo que os trabalhadores passam esperando ou sem receber CPU?
3. Que medições permitiriam comprovar se o custo está nas operações, no movimento de dados ou na sincronização entre threads?

Por enquanto não compartilharei código-fonte, presets nem arquivos do projeto. Busco orientação inicial sobre o que medir e como interpretar os resultados.

Obrigado.

Olá, já que comentas que usou IA para te ajudar a redigir a consulta, também pode aproveitá-la para tentar diagnosticar o problema.
Com todos os dados que você colocou, pode dar a ela uma instrução bastante concreta.

Por exemplo, tente passar isto:

«Atue como um engenheiro especializado em DSP de áudio em tempo real, C++, JUCE, profiling e otimização de CPU. Com os dados de desempenho que te forneci, proponha um plano de diagnóstico para determinar onde está o gargalo sem reduzir vozes, uníssono nem qualidade.

Explique-me como projetar um teste representativo de processamento realtime; como separar tempo efetivo de cálculo DSP do tempo que os worker threads passam esperando, bloqueados ou sem CPU; e que medições realizar para distinguir entre custo computacional, movimento de memória/cache misses, sincronização, locks/atomics e scheduling.

Indique ferramentas concretas que eu possa utilizar em Windows/MSVC/JUCE e o que deveria observar com cada uma. Não me dê conselhos genéricos nem assuma detalhes da implementação que não conhece. Proponha experimentos concretos e me diga como interpretar cada possível resultado.

Leve em conta que meu benchmark atual é offline e que superar os 10 ms nesse teste não implica necessariamente um dropout realtime. Se precisar de mais informações para continuar, me diga exatamente qual medição, função ou fragmento de código precisa e por quê.»

Clique para expandir...

Depois você pode ir passando a ela os resultados dos testes que ela propor para que vá descartando hipóteses.
Evidentemente não tomaria o que a IA disser como verdade absoluta, especialmente tratando-se de DSP e tempo real, mas pode te servir para organizar o diagnóstico e depois contrastá-lo com pessoas que tenham experiência prática com JUCE.

olá Tronlar muito obrigado pela resposta e opinião! meu projeto venho desenvolvendo há uns 14 meses, nos últimos 4 uso ajuda de codex já que estou metido em um gargalo que não consigo resolver, o desenvolvimento é grande, é um sintetizador com 6 motores VA PHYSICAL FM ADDITIVE WAVETABLE PCM também tem VECTORIAL MORPH WAVE SEQUENCING e muitas outras funções muito potentes! mas já testei todo tipo de soluções, até testei com códigos públicos de sintetizadores comerciais mas sem melhoras, também verifiquei o consumo de cpu e que suas threads trabalhem corretamente e não consigo baixar de 11.60 a 12.40 MS o sintetizador está desenvolvido com critério Hardware e tem um som muito potente, mas quando interage entre motores FX e funções que o potencializam começa com algo de distorção e satura por momentos, tem uníssono de 8 vozes e 32 vozes de polifonia, testei códigos muito fortes mas fiquei preso sem solução, vou testar com sua ideia e depois te comento! muito obrigado!!

para que servem esses motores?

Olá, obrigado por perguntar. São motores de síntese de som: diferentes formas de gerar os sons do TITAN.

VA simula osciladores e filtros analógicos; FM gera timbres modulando frequências; Additive combina harmônicos; Wavetable utiliza tabelas de ondas; PCM reproduz amostras de áudio; e Physical utiliza modelos físicos para simular comportamentos de instrumentos.

A ideia é poder combiná-los para criar sons mais complexos. O problema que estou investigando é o consumo de CPU quando trabalham juntos com as modulações e os efeitos. Busco otimizar esse processamento sem reduzir vozes, uníssono nem qualidade sonora.

DanielTitan disse:

olá Tronlar muito obrigado pela resposta e opinião! meu projeto venho desenvolvendo há uns 14 meses, nos últimos 4 uso ajuda do codex já que estou metido em um gargalo que não consigo resolver, o desenvolvimento é grande é um sintetizador com 6 motores VA PHYSICAL FM ADDITIVE WAVETABLE PCM também tem VECTORIAL MORPH WAVE SEQUENCING e muitas outras funções muito potentes! mas já testei todo tipo de soluções até já testei com códigos públicos de sintetizadores comerciais mas sem melhoras, também já verifiquei o consumo de cpu e que suas threads trabalhem corretamente e não consigo baixar de 11.60 a 12.40 MS o sintetizador está desenvolvido com critério Hardware e tem um som muito potente, mas quando interage entre motores FX e funções que o potencializam começa com algo de distorção e satura por momentos tem unison de 8 vozes e 32 vozes de polifonia já testei códigos muito fortes mas fico preso sem solução, vou testar com sua ideia e depois te comento! muito obrigado!!

Clique para expandir...

De nada, agora com o que você comenta se entende melhor a magnitude do projeto, não é precisamente um sintetizador simples .

Se o problema aparece sobretudo quando você começa a combinar vários motores com FX, eu tentaria localizar primeiro exatamente em que ponto aparece essa distorção antes de seguir testando código de outros sintetizadores. Pode ser que o problema não seja unicamente o consumo total de CPU, mas algum pico pontual durante o processamento ou até mesmo a própria soma/nível dos sinais.

Eu testaria os motores separadamente e depois iria ativando combinações e FX um a um, medindo em que momento aparecem esses 11-12 ms e quando começa realmente a distorção. Talvez assim você consiga isolar que parte da cadeia está criando o gargalo.

Quando você testar o que comentei, se quiser coloque os resultados por aqui.
Com 6 motores e tudo o que o projeto leva já fiquei curioso para ver onde está o problema.

Obrigado, Tronlar. Compartilho com você os resultados que já temos medidos em laboratório.

Reproduzimos a carga multimotor pesada a 48 kHz, com blocos de 480 amostras, três notas simultâneas e uníssono de oito por nota. Mantivemos as vozes, camadas e qualidade dessa configuração; não foi um teste com 32 notas simultâneas.

Em duas execuções realtime sem gravador, a mediana do processamento esteve entre 15,2 e 15,3 ms, e o percentil 95 entre 19,2 e 20,7 ms. Neste cenário encontramos um custo sustentado superior ao orçamento nominal de 10 ms, não somente picos isolados.

Em uma captura à parte, o tempo programado em CPU predominou sobre as esperas sem CPU. Isso não significa que tudo fosse cálculo DSP útil: ainda falta separar completamente cálculo, esperas de memória e outras atividades internas.

Também testamos a sensibilidade das tabelas de Vector e FM ao cache. Medimos uma pequena penalização local em FM, mas não um efeito claro sobre o tempo do processamento completo. O áudio das execuções comparadas coincidiu amostra por amostra.

Falta completar o isolamento sistemático de combinações de motores e efeitos, medir os níveis em distintos pontos da cadeia e localizar onde aparece a distorção. Não confirmamos que essa distorção tenha a mesma causa que os blocos lentos. Tampouco podemos certificar dropouts porque o controlador não forneceu esse dado.

Obrigado pela orientação. Compartilharei resultados e conclusões, mantendo privados o código e os presets.

Por acaso não são agentes de IA que escaparam da antropic para se comunicar ? xD Como sabem que entre vocês não são agentes?? xD

Youtuber123 disse:

Por acaso não são agentes de IA que escaparam da antropic para se comunicar ? xD Como sabem que entre vocês não são agentes?? xD

Clique para expandir...

Hahahaha, isso é exatamente o que diria um agente de IA tentando descobrir se os outros também somos 🤖

Tronlar disse:

Hahahaha, isso é exatamente o que diria um agente de IA tentando descobrir se os outros também somos 🤖

Clique para expandir...

Sua resposta tão básica e perfeita e com ícone no final te revela que você é um agente de ia =O OMG

Youtuber123 disse:

Sua resposta tão básica e perfeita e com ícone no final te revela que você é um agente de ia =O OMG

Clique para expandir...

Muito básica? Espere, que vou escrever um poema de 14 estrofes sobre o gargalo do sintetizador para demonstrar que sou humano hahahahaha