BookinglyTech News
Software

SoundScript une TTS local y en la nube con una caché que evita pagar dos veces

La app de escritorio de un desarrollador independiente usa Kokoro y Qwen en local, y ElevenLabs y Gemini en la nube, con una caché por hash que elimina el coste de repetir una generación.

3 min de lecturaDev.to0 vistas

SoundScript es una aplicación de escritorio que coloca cuatro motores de texto a voz —dos en la nube y dos locales— detrás de la misma interfaz, con una capa de caché por delante de todos ellos. El autor la construyó después de que le molestaran dos cosas del TTS en la nube: que cada regeneración cuesta dinero aunque solo arregles una palabra de un guion de 500, y que enviar guiones sin publicar de clientes bajo NDA a una API de terceros no es una opción.

Cuatro motores y una caché por encima

El reparto es el siguiente. ElevenLabs cubre la nube con pago por carácter y clave de API propia. Gemini también va en la nube con nivel gratuito, eso sí, con clave. Anhad es local y se apoya en Kokoro-82M, un modelo de 82 millones de parámetros con licencia Apache-2.0 que corre sobre ONNX Runtime: unos 340 MB de modelo, 15 voces en inglés de Estados Unidos y Reino Unido, todo en CPU. Nuqta es Qwen servido con llama.cpp, disponible en varios tamaños para cambiar calidad por velocidad según la máquina, entre 400 MB y 2,5 GB.

La pieza que de verdad sostiene el invento no es la interfaz sino la caché. El hash de texto, identificador de voz, estabilidad, similitud y velocidad se usa como nombre de fichero, y antes de tocar cualquier backend se comprueba si ese audio ya está en disco. El resultado es que generar dos veces la misma línea sale gratis, que se puede comparar dos lecturas y quedarse con una, o mover una coma sin mirar el contador. El hash es el mismo para motores locales y remotos, así que el flujo no cambia según dónde se sintetice. El autor asegura que le costó muy poco código adicional.

A eso suma un asistente que lee un fragmento del guion y propone la emoción dominante y los valores de estabilidad y similitud, para no gastar créditos tanteando deslizadores a ciegas. El propio autor reconoce que las sugerencias no son perfectas: la dirección de voz es subjetiva y el modelo no escucha la voz que hayas elegido.

Empaquetar fue lo difícil

El stack es Python en todo, con PySide6 para la interfaz, onnxruntime para Kokoro, llama-cpp-python para Qwen y lameenc para codificar MP3. Meter ONNX Runtime y llama.cpp en un único ejecutable de Windows con PyInstaller, sin arrastrar una dependencia CUDA de 2 GB, le llevó varios intentos. Su consejo para quien lo intente: compila primero solo CPU y saca la versión GPU como canal de distribución aparte, no como un flag de compilación. El binario se queda pequeño y la instalación rápida.

De lo que haría distinto, menciona tres cosas: empezar por la caché y no por la interfaz, diseñar para el modo sin conexión desde el primer día y recortar alcance. Cuatro motores, viene a decir, son cuatro madrigueras, y los dos últimos casi se llevan el proyecto por delante.

SoundScript se vende como aplicación de pago a 29 dólares, pago único, sin suscripción, sin telemetría y sin cuenta. Los motores locales funcionan sin conexión tras descargar los modelos, en Windows 10/11 y Linux.

Para quien no vaya a comprarla, lo aprovechable son dos patrones. El primero es la caché por hash colocada por encima de motores locales y remotos por igual: sirve para cualquier pipeline de generación con coste por llamada, no solo para voz. El segundo es la lección de empaquetado, compilar solo CPU y separar la GPU en otro canal, que se aplica a cualquier binario que embeba runtimes de inferencia. Todo lo demás son cifras y afirmaciones del autor, que no ha publicado una demo ni datos de rendimiento comparables.