Problem
XVF3800 LED ring worked inconsistently (~50% success rate at startup) due to: 1. Timing race: LED commands sent before WS2812 power (X0D33) enabled 2. Missing context manager: USB resources could leak on exceptions
Changes
Context Manager Support (Critical Fix B)
Added __enter__ and __exit__ methods to _ReSpeaker class
Enhanced close() with proper null checks and error handling
Enables safe with statement usage
LED Power Management (NEW Critical Fix)
Proactive initialization: Enable X0D33 immediately in __init__ before any LED operations
Defensive runtime checks: Added _ensure_led_power() helper method
Power verification: Check X0D33 state before set_effect() and set_ring_colors()
Added 50ms settle time after enabling power
Documentation
Added GPO_WRITE_VALUE and GPO_READ_VALUES to PARAMETERS dict
Added GPO_WS2812_POWER_INDEX constant for clarity
Enhanced inline comments explaining power management
Extends the existing XVF3800 USB control backend beyond LEDs to support startup preflight commands needed for audio reliability.
Implements command execution internally (no reliance on xvf_host.py) using the same USB control-transfer approach already used for LED features.
Added support for the XVF3800 per-LED command LED_RING_COLOR (12-LED ring, 48-byte payload).
Implemented/readied the device control logic so the backend can:
write per-LED frames (set_ring_rgb / set_ring_solid / clear_ring),
detect availability (supports_per_led) and fall back if unsupported.
Improved robustness/diagnostics for USB control transfers (more consistent request composition + debug logging around writes).
imonlinux