Caídas en transferencias isócronas USB: depurando clicks de audio, congelaciones de webcam y frames de vídeo perdidos
Cómo depurar caídas en transferencias isócronas USB, clicks en audio, congelaciones de webcam, pérdida de frames UVC, límites de ancho de banda, alternate settings y streams USB sensibles al timing.
Los dispositivos de audio y vídeo USB suelen fallar de una forma que no parece un error de petición normal. Un micrófono chasquea. Una interfaz de audio hace pop. Una webcam se congela un instante. Un dispositivo de captura pierde frames. Una cámara UVC va a 720p pero falla a 1080p. Los usuarios buscan "USB isochronous transfer dropout", "USB audio clicks packet loss", "webcam freezes USB bandwidth", "UVC frame drop" y "USB isochronous error" porque la aplicación suele reportar solo un glitch, no la causa a nivel de bus.
Las transferencias isócronas están pensadas para datos sensibles al tiempo. Priorizan la entrega regular sobre el reintento. Es perfecto para audio y vídeo, pero cambia la troubleshooting. Un paquete isócrono que falla no se retransmite como una bulk transfer. Si se pierde la time slot, la muestra de audio o el frame de vídeo se pierde.
Bus Scope ayuda porque los problemas isócronos van de timing, endpoints, alternate settings, estado de los paquetes y reserva de ancho de banda. Tienes que inspeccionar el stream USB en sí.
Para qué se usan las transferencias isócronas
Las transferencias isócronas son habituales en:
- Micrófonos USB.
- Altavoces USB.
- Interfaces de audio.
- Webcams USB.
- Cámaras UVC.
- Dispositivos de captura HDMI.
- Dispositivos de streaming médico o industrial.
- Streams de sensores sensibles al tiempo.
El host reserva ancho de banda para estas transferencias. El dispositivo envía o recibe datos a intervalos regulares. El sistema espera que el pipeline de medios gestione los errores ocasionales, no que retransmita.
Por qué hay caídas
Causas habituales:
- No hay suficiente ancho de banda USB en el bus.
- Se eligió el alternate setting equivocado.
- Hub compartido con otros dispositivos de alto ancho de banda.
- Dispositivo USB 2.0 usado por un camino limitado.
- Presión de scheduling del host controller.
- Underrun o overrun del firmware del dispositivo.
- La aplicación no consume frames lo bastante rápido.
- Power management que interrumpe el timing del stream.
- Problemas de cable o integridad de señal.
- Driver que eligió un modo demasiado agresivo para el bus real.
El síntoma visible depende del tipo de medio. Las caídas de audio se vuelven clicks, pops, silencios o drift. Las de vídeo se vuelven frames congelados, corrupción, frames repetidos o caída del frame rate.
Los alternate settings importan
Los dispositivos de audio y vídeo USB suelen exponer varios alternate settings. Un alternate setting de la interfaz puede definir packet sizes o modos de streaming distintos. El host selecciona un alternate setting antes de empezar el streaming.
Una traza puede enseñar:
SET_INTERFACE interface=1 alternate=3
Isochronous IN transfers begin
Si el driver selecciona un alternate setting que pide más ancho de banda del que el bus puede dar de forma fiable, el stream puede fallar bajo carga. Si un alternate setting de menor ancho de banda va, la presión de scheduling o de ancho de banda es la candidata.
Pérdida de frames en cámaras UVC
Los dispositivos USB Video Class suelen mandar frames por endpoints isócronos. Un único frame de vídeo puede abarcar muchos paquetes USB. Si faltan algunos paquetes o vienen marcados con error, el frame puede quedar incompleto.
Síntomas:
- La preview de la webcam se congela.
- Baja el frame rate.
- Fallan algunas resoluciones.
- MJPEG va pero YUY2 sin comprimir falla.
- 1080p falla pero 720p va.
- La cámara va sola pero falla a través de un hub.
La evidencia de paquetes debería enseñar el tráfico del endpoint, el estado de los paquetes, los límites de frame cuando estén disponibles y si los errores se agrupan en periodos de alto ancho de banda.
Clicks y pops en audio USB
El audio es sensible al timing. Hasta huecos pequeños pueden producir artefactos audibles. Al contrario que una transferencia de ficheros, el sistema no puede esperar y reintentar sin meter latencia.
Busca:
- Paquetes isócronos con error status.
- Huecos periódicos.
- Comandos de start o stop de stream antes de los glitches.
- Cambios de sample rate.
- Transiciones de estado de power.
- Carga del host controller.
- Otro dispositivo que empieza tráfico de alto ancho de banda en el mismo bus.
Si los glitches pasan solo cuando una cámara o un disco está activo en el mismo hub, la contención del bus es una sospechosa fuerte.
Caminos full-speed, high-speed y SuperSpeed
La velocidad USB importa. Un dispositivo conectado a través de un hub o adaptador puede operar a una velocidad menor de la esperada. Una cámara USB 2.0 no puede superar el ancho de banda práctico de su camino. Un dispositivo de captura USB 3.x conectado por un cable malo puede caer o volverse inestable.
La traza y los descriptores del dispositivo pueden enseñar la velocidad negociada y los packet sizes del endpoint. Es más fiable que asumir por la forma del conector.
Power management y transiciones de idle
Los dispositivos de streaming pueden fallar tras idle, bloqueo de pantalla, sleep/resume o selective suspend. El primer stream tras el resume puede tener paquetes perdidos o requerir reinicialización.
Si un dispositivo funciona tras enchufarlo pero se cae tras idle, captura la transición a idle y la primera secuencia de stream-start tras el idle. El fallo puede no ser de ancho de banda, sino de estado de resume.
Estrategia de captura
Para depurar caídas isócronas:
- Captura desde antes del stream start.
- Apunta la configuración y el alternate setting seleccionado.
- Mantén visibles los endpoint descriptors.
- Captura hasta el primer dropout audible o visible.
- Marca el momento aproximado del glitch visible para el usuario.
- Inspecciona el estado de los paquetes en torno a ese momento.
- Compara resoluciones o sample rates que funcionan con los que fallan.
- Compara directo al puerto frente a hub.
No recortes demasiado pronto los setup packets. El alternate setting seleccionado suele ser esencial.
Checklist para caídas isócronas USB
Usa este proceso:
- Identifica la velocidad del dispositivo y el camino del bus.
- Inspecciona descriptores y endpoints isócronos.
- Identifica el alternate setting seleccionado.
- Compara el ancho de banda necesario con las condiciones del bus.
- Busca errores de packet status en torno al dropout.
- Mira si otro dispositivo de alto ancho de banda arranca tráfico.
- Prueba resolución, frame rate o sample rate más bajos.
- Prueba directo al puerto, otro controller y un hub con alimentación.
- Revisa el timing de suspend/resume.
- Conserva el timing de los paquetes al compartir la traza.
Diagnóstico final
Las caídas isócronas USB son tanto problemas de timing y scheduling como de dispositivo. Clicks de audio y congelaciones de webcam pueden venir de límites de ancho de banda, alternate settings, presión del host controller, topología de hubs, power management, timing del firmware o retrasos de consumo en la aplicación.
Bus Scope ayuda enseñando la evidencia real del stream USB, para que un glitch de medios se diagnostique como un problema de timing a nivel de bus, y no solo como un fallo vago de la aplicación.