CDJ emulation con QEMU: laboratorio aislado y test/rollback.

Hay una pregunta que parece una y en realidad son cuatro: ¿puedo probar mi software contra un CDJ sin tener un CDJ delante? La respuesta depende de qué quieras probar. Emular la capa de red de un reproductor, emular su protocolo USB, reproducir su interfaz o ejecutar su firmware son caminos distintos, con distinto coste y con distinto estado de disponibilidad.

Esta guía continúa Emular un CDJ para pruebas, donde ya se separó emular el protocolo de ejecutar el firmware del fabricante. Aquí toca montar el banco de pruebas: qué papel juega QEMU, cómo se construye un laboratorio aislado que no dependa de tu cabina y cómo se organiza un ciclo de test/rollback para que un fallo cueste un reinicio y nada más.

Qué es la CDJ emulation y qué no promete

La CDJ emulation no es una cosa sola. En la práctica hay cuatro capas, y cada una tiene su vía:

• Capa de red. Un dispositivo virtual que se presenta en la red DJ Link como un reproductor más: recibe lo que circula y publica lo suyo. Es lo que hace una biblioteca de interoperabilidad, y es la vía documentada.
• Capa USB/HID. La conversación entre el equipo y el ordenador: botones, LEDs, informes de estructura fija. Está documentada desde fuera, con cabecera 0x20 de entrada y 0x21 de salida.
• Capa de interfaz. La pantalla y lo que muestra: ondas, portada, posición del playhead. Se puede simular, pero simularla no es emular el equipo.
• Capa de firmware. El software que arranca dentro del reproductor. Ahí no hay método verificado publicado, y esta guía no explica cómo ejecutarlo.

La tabla de abajo ordena esas cuatro y añade la que la gente olvida al empezar: el hardware real. Mírala antes de decidir qué vas a probar, porque la última columna es la que decide cuánto puedes permitirte experimentar.

QEMU en el laboratorio: emulador y virtualizador

QEMU se define en su propia documentación como un emulador de máquina y virtualizador genérico y de código abierto, y ofrece tres formas de trabajo: emulación de sistema completo, para arrancar sistemas operativos en cualquier arquitectura soportada; emulación de usuario, para ejecutar programas de otro objetivo; y virtualización con rendimiento próximo al nativo sobre KVM o Xen.

Para un laboratorio de DJ interesa la primera, y dentro de ella tres recursos sostienen el montaje:

• Imágenes de disco. QEMU trabaja con imágenes crecientes, comprimidas y cifradas; los formatos recomendados son raw y qcow2, y este último admite múltiples snapshots.
• Modo snapshot con -snapshot. Todas las imágenes de disco se tratan como de solo lectura y cada escritura va a un fichero temporal. Nada de lo que ocurra dentro toca la imagen base, y aun así puedes forzar el commit si decides conservar los cambios.
• Snapshots de máquina completa. Con savevm se guarda el estado completo —CPU, memoria, estado de dispositivos y contenido de los discos— y con loadvm se vuelve a ese punto exacto. info snapshots lista lo disponible y delvm elimina una entrada.

Dos límites que conviene conocer antes de prometer nada: los snapshots no soportan bien los dispositivos extraíbles que cambian después de guardarlos, y algunos controladores, USB entre ellos, tienen soporte incompleto de snapshot. Además, QEMU bloquea las fichas de imagen para evitar accesos concurrentes: si dos procesos intentan abrir la misma imagen en modo conflictivo, solo el primero continúa.

Sobre esa base montas un sistema operativo, y dentro de él tu software y tus herramientas de red. La hipervisor es solo el suelo del laboratorio; el resto lo pones tú.

Laboratorio aislado: red, imágenes y copias

Un laboratorio aislado no es una carpeta llamada pruebas. Son cuatro decisiones tomadas antes de la primera prueba:

• Red aparte. Si el laboratorio comparte red con la cabina, una prueba malograda acaba en el escenario que usas para trabajar. Un segmento propio, o una red sin salida, evita que un participante mal construido ensucie la red real.
• Imágenes base de solo lectura. La plantilla limpia nunca se toca: se copia, se lanza la copia y se descarta. La regla es que cualquier estado del laboratorio sea recreable desde la plantilla, no reparable a mano.
• Participantes virtuales en lugar de hardware. Un dispositivo virtual ocupa el hueco de un reproductor sin meter miles de euros sobre la mesa. La documentación de la biblioteca de referencia describe un Virtual CDJ que obtiene información detallada de los demás reproductores: tempo actual, pitch, estado de reproducción, quién es el tempo master y el origen e identificador de base de datos de la pista cargada.
• Cero dependencia de producción. Nada de bibliotecas reales sin copiar, nada de credenciales de trabajo, nada de equipo de cabina «solo para probar un momento».

Hay un techo documentado en la propia vía buena: con cuatro reproductores en uso, la interfaz con el servidor de base de datos no es fiable, porque el laboratorio no puede ocupar un número de reproductor real. La alternativa que describe esa misma documentación es descargar los ficheros de exportación desde los servidores NFSv2 de los reproductores, que no dependen de ese número. Si tu prueba toca ese flanco, ya sabes dónde está el techo.

Test/rollback: repetir el fallo y volver atrás

El ciclo tiene dos mitades que solo se entienden juntas.

Test significa repetir. El mismo escenario, con el mismo estado inicial, tantas veces como haga falta hasta ver el fallo: una prueba que no es repetible no es una prueba, es una anécdota. Antes de lanzarla se toma un snapshot con etiqueta y fecha; después se ejecuta, se anota qué versión de qué componente estaba corriendo y qué pasó.

Rollback significa volver a un estado conocido. En el laboratorio es baratísimo: loadvm devuelve la máquina al punto guardado y el modo -snapshot ni siquiera deja residuos en la imagen base. El coste real está en lo que no se puede rebobinar: el firmware de un equipo físico. Si algo se instala ahí, no hay snapshot que lo salve.

Por eso el ciclo se escribe antes de empezar:

1. Estado limpio etiquetado, con fecha y versión incluidas.
2. Prueba con un único cambio respecto al estado anterior.
3. Anotación del resultado, sea positivo o negativo.
4. Vuelta al estado limpio antes del siguiente cambio.

Si saltas el paso cuatro, dejas de saber qué causó qué, y el banco de pruebas deja de ser un laboratorio para convertirse en una colección de fallos sueltos.

Qué se puede probar y qué no

Se prueba bien: aparición y desaparición de dispositivos en la red, sincronización de tempo, lectura de metadatos y ondas, reacción de tu herramienta ante estados incómodos —un jugador que se cae, un cambio de tempo master, una pista que se recarga— y en general todo lo que se expresa en mensajes observables.

No se prueba nada el tacto del jog, la latencia real ni la ruta de audio. Tampoco se prueba el HID si tu herramienta vive en la red: un participante virtual no habla HID, porque esa conversación es local y viaja por USB. Si tu problema es leer controles o encender LEDs de un equipo concreto, necesitas trabajar contra la especificación observada de esa capa, no contra el laboratorio de red.

Y queda una tercera categoría, la que más decepciona: comprobar que «funciona con el equipo real». Eso no se emula. Se verifica con el aparato delante, en su red, con su firmware exacto y su fecha.

Límites, riesgos y la línea que no se cruza

• El protocolo observado no es un contrato. Lo documentado refleja lo que se vio en un momento dado, y una actualización puede cambiarlo sin avisar.
• Un participante mal construido ensucia el laboratorio. Si tu virtual se comporta mal, el fallo aparece lejos de su causa y pierdes la repetibilidad, que es lo único que hacía valer al banco.
• No se redistribuye firmware propietario. Se analiza, se describe y se cita; no se empaqueta ni se aloja.
• Las normas varían por país y esta guía no da asesoramiento jurídico. La práctica de la comunidad técnica es trabajar sobre equipo propio, con propósito de interoperabilidad y documentando lo observado.
• Si tu plan depende de saltarse una protección, el laboratorio no lo arregla. El montaje sirve para probar dentro de lo soportado; no convierte lo que queda fuera en algo seguro.

Siguiente paso

Ya tienes el banco de pruebas montado en la cabeza: capas separadas, una virtualizador con snapshots, red aislada y un ciclo de test/rollback que no depende del equipo de cabina. El paso siguiente es usarlo contra la red de verdad: qué es Pro DJ Link, cómo se organiza y qué se puede hacer desde fuera del ecosistema oficial. Ese terreno se abre en Qué es Pro DJ Link, y la pieza que pondrás en marcha durante las siguientes pruebas es la que explica Qué es un Virtual CDJ, que es donde continúa esta guía.