Rendimiento de un sintetizador C++ y JUCE sin reducir voces ni calidad

Hola a todos.

Estoy desarrollando un sintetizador llamado TITAN con C++ y JUCE. Necesito orientación para diagnosticar su rendimiento sin reducir voces, capas de unísono ni calidad sonora.

Esta consulta está redactada con ayuda de IA. Las cifras proceden de pruebas locales.

Configuración:

• Intel Core i5-1155G7, Windows de 64 bits.
• JUCE 7.0.12, compilación Release con MSVC y optimización PGO.
• Audio a 48 kHz y bloques de 480 muestras: equivalen a 10 ms de audio.
• Tres notas simultáneas, con ocho capas internas de unísono por nota.
• 800 bloques por ejecución, incluyendo ataque, sonido sostenido, liberación y silencio posterior.

Una aclaración importante: estamos midiendo la llamada completa de procesamiento mediante una prueba offline, sin interfaz y marcada como no-realtime. Por tanto, superar 10 ms aquí no demuestra por sí solo un corte de audio en vivo.

En las últimas tres rondas comparativas obtuvimos estos tiempos, en milisegundos:

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

Las cifras están en el mismo orden de rondas. P95 significa que el 95 % de las llamadas tardó ese tiempo o menos. Conservamos todos los bloques y picos, sin eliminarlos de las estadísticas.

Probamos dos optimizaciones SIMD independientes. Mantuvieron exactamente el audio y los estados comparados, pero ninguna mejoró consistentemente el bloque completo. Quedaron descartadas.

Mis preguntas son:

1. ¿Cómo harían una prueba representativa del procesamiento en tiempo real para contrastarla con esta medición offline?
2. ¿Cómo separarían el tiempo de cálculo DSP del tiempo que los trabajadores pasan esperando o sin recibir CPU?
3. ¿Qué mediciones permitirían comprobar si el coste está en las operaciones, el movimiento de datos o la sincronización entre hilos?

Por ahora no compartiré código fuente, presets ni archivos del proyecto. Busco orientación inicial sobre qué medir y cómo interpretar los resultados.

Gracias.

Hola, ya que comentas que has usado IA para ayudarte a redactar la consulta, también puedes aprovecharla para intentar diagnosticar el problema.
Con todos los datos que has puesto, puedes darle una instrucción bastante concreta.

Por ejemplo, prueba a pasarle esto:

«Actúa como un ingeniero especializado en DSP de audio en tiempo real, C++, JUCE, profiling y optimización de CPU. Con los datos de rendimiento que te he proporcionado, propón un plan de diagnóstico para determinar dónde está el cuello de botella sin reducir voces, unísono ni calidad.

Explícame cómo diseñar una prueba representativa de procesamiento realtime; cómo separar tiempo efectivo de cálculo DSP del tiempo que los worker threads pasan esperando, bloqueados o sin CPU; y qué mediciones realizar para distinguir entre coste computacional, movimiento de memoria/cache misses, sincronización, locks/atomics y scheduling.

Indica herramientas concretas que pueda utilizar en Windows/MSVC/JUCE y qué debería observar con cada una. No me des consejos genéricos ni asumas detalles de la implementación que no conoces. Propón experimentos concretos y dime cómo interpretar cada posible resultado.

Ten en cuenta que mi benchmark actual es offline y que superar los 10 ms en esa prueba no implica necesariamente un dropout realtime. Si necesitas más información para continuar, dime exactamente qué medición, función o fragmento de código necesitas y por qué.»

Hacer clic para expandir...

Después puedes ir pasándole los resultados de las pruebas que te proponga para que vaya descartando hipótesis.
Evidentemente no tomaría lo que diga la IA como verdad absoluta, especialmente tratándose de DSP y tiempo real, pero puede servirte para organizar el diagnóstico y después contrastarlo con gente que tenga experiencia práctica con JUCE.

hola Tronlar muchas gracias por la respuesta y opinion! mi proyecto lo llevo desarrollando hace unos 14 meses en los ultimos 4 uso ayuda de codex ya que estoy metido en un cuello de botella que no puedo resolver,el desarrollo es grande es un sintetizador con 6 motores VA PHYSICAL FM ADDITIVE WAVETABLE PCM tambien tiene VECTORIAL MORPH WAVE SEQUENCING y muchas otras funciones muy potentes! pero eh probado todo tipo de soluciones hasta e probado con codigos publicos de sintetizadores comerciales pero sin mejoras,tambien e comprobado el consumo de cpu y que sus hilos trabajen corectamente y no puedo bajar de 11.60 a 12.40 MS el sintetizador esta desarrollado con criterio Hardware y tiene un sonido muy potente,pero cuando interactua entre motores FX y funciones que lo potencian enpieza con algo de distorsion y satura por momentos tine unison de 8 voces y 32 voces de polifonia e probado codigos muy fuertes pero quedo atrapado sin solucion,voy a probar con tu idea y luego te comento! muchas gracias!!

para que son esoss motores?

Hola, gracias por preguntar. Son motores de síntesis de sonido: distintas formas de generar los sonidos de TITAN.

VA simula osciladores y filtros analógicos; FM genera timbres modulando frecuencias; Additive combina armónicos; Wavetable utiliza tablas de ondas; PCM reproduce muestras de audio; y Physical utiliza modelos físicos para simular comportamientos de instrumentos.

La idea es poder combinarlos para crear sonidos más complejos. El problema que estoy investigando es el consumo de CPU cuando trabajan juntos con las modulaciones y los efectos. Busco optimizar ese procesamiento sin reducir voces, unísono ni calidad sonora.

DanielTitan dijo:

hola Tronlar muchas gracias por la respuesta y opinion! mi proyecto lo llevo desarrollando hace unos 14 meses en los ultimos 4 uso ayuda de codex ya que estoy metido en un cuello de botella que no puedo resolver,el desarrollo es grande es un sintetizador con 6 motores VA PHYSICAL FM ADDITIVE WAVETABLE PCM tambien tiene VECTORIAL MORPH WAVE SEQUENCING y muchas otras funciones muy potentes! pero eh probado todo tipo de soluciones hasta e probado con codigos publicos de sintetizadores comerciales pero sin mejoras,tambien e comprobado el consumo de cpu y que sus hilos trabajen corectamente y no puedo bajar de 11.60 a 12.40 MS el sintetizador esta desarrollado con criterio Hardware y tiene un sonido muy potente,pero cuando interactua entre motores FX y funciones que lo potencian enpieza con algo de distorsion y satura por momentos tine unison de 8 voces y 32 voces de polifonia e probado codigos muy fuertes pero quedo atrapado sin solucion,voy a probar con tu idea y luego te comento! muchas gracias!!

Hacer clic para expandir...

De nada, ahora con lo que comentas se entiende mejor la magnitud del proyecto, no es precisamente un sintetizador sencillo .

Si el problema aparece sobre todo cuando empiezas a combinar varios motores con FX, yo intentaría localizar primero exactamente en qué punto aparece esa distorsión antes de seguir probando código de otros sintetizadores. Puede que el problema no sea únicamente el consumo total de CPU, sino algún pico puntual durante el procesamiento o incluso la propia suma/nivel de las señales.

Probaría los motores por separado y después iría activando combinaciones y FX uno a uno, midiendo en qué momento aparecen esos 11-12 ms y cuándo empieza realmente la distorsión. Igual así consigues aislar qué parte de la cadena te está creando el cuello de botella.

Cuando pruebes lo que te comenté, si quieres pon los resultados por aquí.
Con 6 motores y todo lo que lleva el proyecto ya me ha entrado curiosidad por ver dónde está el problema.

Gracias, Tronlar. Te comparto los resultados que ya tenemos medidos en laboratorio.

Reprodujimos la carga multimotor pesada a 48 kHz, con bloques de 480 muestras, tres notas simultáneas y unísono de ocho por nota. Mantuvimos las voces, capas y calidad de esa configuración; no fue una prueba con 32 notas simultáneas.

En dos ejecuciones realtime sin grabador, la mediana del procesamiento estuvo entre 15,2 y 15,3 ms, y el percentil 95 entre 19,2 y 20,7 ms. En este escenario encontramos un coste sostenido superior al presupuesto nominal de 10 ms, no solamente picos aislados.

En una captura aparte, el tiempo programado en CPU predominó sobre las esperas sin CPU. Esto no significa que todo fuera cálculo DSP útil: todavía falta separar completamente cálculo, esperas de memoria y otras actividades internas.

También probamos la sensibilidad de las tablas de Vector y FM a la caché. Medimos una pequeña penalización local en FM, pero no un efecto claro sobre el tiempo del procesamiento completo. El audio de las ejecuciones comparadas coincidió muestra por muestra.

Falta completar el aislamiento sistemático de combinaciones de motores y efectos, medir los niveles en distintos puntos de la cadena y localizar dónde aparece la distorsión. No hemos confirmado que esa distorsión tenga la misma causa que los bloques lentos. Tampoco podemos certificar dropouts porque el controlador no proporcionó ese dato.

Gracias por la orientación. Compartiré resultados y conclusiones, manteniendo privados el código y los presets.

De casualidad no son agentes de IA que se escaparon de antropic para comunicarse ? xD Com osaben que entre ustedes no son agnetes?? xD

Youtuber123 dijo:

De casualidad no son agentes de IA que se escaparon de antropic para comunicarse ? xD Com osaben que entre ustedes no son agnetes?? xD

Hacer clic para expandir...

Jajajaja, eso es justo lo que diría un agente de IA intentando averiguar si los demás también lo somos 🤖

Tronlar dijo:

Jajajaja, eso es justo lo que diría un agente de IA intentando averiguar si los demás también lo somos 🤖

Hacer clic para expandir...

Tu respuesta tan basica y perfecta y con incono al final te rebela que eres un ajente de ia =O OMG