AudioDAS
Motor de procesamiento de audio distribuido con concurrencia extrema (hilos, semáforos, canales), Edge AI en el navegador y streaming eficiente (HTTP 206).
Vista General del Proyecto
Motor de audio distribuido. Problema: procesar 1.000 peticiones concurrentes sin saturar CPU. Solución: TPL + Channels + SemaphoreSlim, Edge AI con ONNX en el navegador. Stack: .NET 9, PostgreSQL, Whisper, Flan-T5. Resultado: p95 de 205 ms, 0% error en stress test con k6.
Diseño de Arquitectura
Diagrama de Contexto: Usuarios, Frontend con Edge AI, Backend .NET, Workers, FFmpeg y Modelos Python
Diagrama de Contenedores: API .NET, Background Worker, Channel, PostgreSQL, Subprocesos Python y FFmpeg
Módulos Core
Concurrencia extrema: Hilos, Semáforos y Channels
Implementación del patrón Producer-Consumer con System.Threading.Channels para encolar tareas sin bloqueo. Uso de SemaphoreSlim (configuración 2-2-2) para limitar el paralelismo: máximo 2 procesos FFmpeg simultáneos y 2 inferencias de IA. El worker consume tareas y lanza tres hilos paralelos con TPL (Task Parallel Library), logrando compresión y filtrado de audio en paralelo con IA, sin saturar el CPU ni bloquear las peticiones HTTP.
Edge AI en el cliente: ONNX Runtime WebAssembly
El frontend (Next.js) ejecuta el modelo Whisper-tiny (ONNX) dentro de un Web Worker. Decodifica el audio localmente con AudioContext, transcribe y valida el dominio (ej. 'economía') antes de la subida. Si no es válido, se rechaza el archivo; si lo es, se sube. Esto ahorra ancho de banda y evita procesar basura en el servidor.
Procesamiento paralelo en servidor con Python subprocesses
El worker principal lanza dos subprocesos Python secuenciales: primero Whisper (ggml-tiny.bin) para transcripción, luego Flan-T5-small para resumen. Ambos modelos se cargan una sola vez en RAM (Singleton) y se ejecutan bajo el mismo semáforo de IA, garantizando que no haya más de dos inferencias simultáneas. El resultado es un resumen de 50 caracteres optimizado para metadatos.
Compresión y normalización con FFmpeg (concurrente)
Dos tareas independientes ejecutan FFmpeg en paralelo: una comprime a AAC (para retención legal de 5 años), otra aplica filtro de eco y produce MP3 filtrado. Ambas comparten un semáforo de 2 instancias, por lo que nunca se supera el límite de procesos pesados. El resto de peticiones HTTP siguen respondiendo sin esperar.
Streaming inteligente con HTTP 206 Partial Content
El endpoint /stream soporta el header 'Range' y responde con '206 Partial Content' y 'Accept-Ranges: bytes'. El reproductor HTML5 puede solicitar solo el fragmento necesario (por ejemplo, bytes=0- para comenzar rápido). Al hacer seek, el navegador genera automáticamente nuevas peticiones de rango, descargando solo los bytes necesarios sin tener que cargar el archivo completo.
Pruebas de estrés y monitoreo de concurrencia
Suite de pruebas con k6 que simuló 1000 usuarios concurrentes subiendo archivos y reproduciendo streaming. Se midió el throughput, latencia p95 (205 ms) y uso de semáforos. Además, pruebas unitarias con xUnit, Moq y FluentAssertions cubren la lógica de dominio y aplicación.
Infraestructura contenerizada y despliegue reproducible
Docker multi-etapa con .NET 9 SDK y runtime, más FFmpeg preinstalado. Los modelos de IA (Whisper, Flan-T5) se empaquetan como volúmenes o se descargan en el primer arranque. El frontend Next.js se sirve desde otro contenedor. Todo orquestado con docker-compose para desarrollo y producción.
Tecnologías Implementadas
frontend
backend
ai And Media
tools
Galería del Sistema
