USB Alternate Setting and Bandwidth Debugging
How to debug USB alternate settings, bandwidth reservation, UVC camera modes, audio sample rates, isochronous endpoints, interface switching, and high-quality stream failures.
A UVC camera that is stable at 720p may freeze at 1080p, while a USB audio interface that is clean at 48 kHz may click at 192 kHz. That pattern points to USB alternate setting bandwidth or a failed SET_INTERFACE transition, not a completely dead device. Comparing the selected UVC camera alternate setting, USB audio isochronous bandwidth, and the first failing transfer can show which interface mode broke; it cannot by itself prove whether the limit belongs to the host controller, hub, cable, or firmware.
Bus Scope is useful because alternate settings are visible in descriptors and SET_INTERFACE requests. The key evidence is which alternate setting was selected before the failure.
Direct answer: capture the full interface descriptors, map each alternate setting to its endpoints and periodic capacity, then find the SET_INTERFACE request that activates the working or failing mode. Compare speed, endpoint fields, requested media mode, transfer status, and topology. Alternate 0 often disables streaming; a higher alternate enables one or more endpoints. A successful SET_INTERFACE proves selection, not sustained error-free delivery.
What alternate settings are
A USB interface can define multiple alternate settings. Alternate setting 0 often has no streaming endpoints. Higher alternate settings may enable endpoints with different packet sizes or bandwidth requirements.
Example:
Interface 1 alternate 0: no streaming
Interface 1 alternate 1: low bandwidth endpoint
Interface 1 alternate 2: medium bandwidth endpoint
Interface 1 alternate 3: high bandwidth endpoint
The host selects one using:
SET_INTERFACE interface=1 alternate=3
If alternate 3 requires more bandwidth than the bus can provide, streaming may fail.
UVC camera modes
USB Video Class cameras often expose many modes:
- MJPEG vs uncompressed YUY2
- 720p vs 1080p vs 4K
- 15 fps vs 30 fps vs 60 fps
- Different endpoint packet sizes
- Different alternate settings
Uncompressed video can require much more bandwidth than MJPEG. A camera may enumerate correctly but fail when the application selects an aggressive mode.
USB audio sample rates
Audio interfaces may switch alternate settings for sample rate, channel count, bit depth, and packet size. A mode that works on one host controller may fail through a hub or dock.
Symptoms:
- Clicks and pops at high sample rate.
- Stream fails only with many channels.
- Device works after reconnect but fails after mode switch.
- Audio stops when another USB device starts traffic.
The bus trace should show the selected alternate setting and isochronous packet status.
Bandwidth reservation
Isochronous and interrupt transfers reserve periodic bandwidth. If the bus cannot satisfy the request, the host may reject the interface selection or the stream may run poorly.
Bandwidth pressure comes from:
- Multiple cameras on one hub.
- USB audio plus capture device.
- Full-speed device behind a transaction translator.
- Dock topology.
- Host controller scheduling limits.
- Cable causing speed fallback.
Debug checklist
Use this workflow:
- Capture descriptors from plug-in.
- List alternate settings for the streaming interface.
- Capture the
SET_INTERFACErequest. - Record selected alternate setting.
- Compare working and failing quality modes.
- Inspect endpoint max packet size and interval.
- Check negotiated device speed.
- Test direct port vs hub/dock.
- Reduce resolution, frame rate, sample rate, or channel count.
- Preserve setup and streaming packets together.
Final diagnosis
USB alternate setting failures are mode-selection and bandwidth problems. A device can enumerate and work in one mode but fail when the host selects a higher-bandwidth alternate setting.
Bus Scope helps expose the selected interface mode and endpoint evidence so high-quality streaming failures can be diagnosed as USB bandwidth and descriptor behavior, not generic application instability.
Interface numbers and alternates are a two-part key
An alternate setting belongs to one interface. alternate 2 on interface 1 is unrelated to alternate 2 on interface 3.
Record:
| Field | Meaning |
|---|---|
bInterfaceNumber |
Logical interface selected by wIndex |
bAlternateSetting |
Alternate selected by wValue |
bNumEndpoints |
Endpoints active for this alternate |
| Interface class/subclass/protocol | Driver and class interpretation |
| Endpoint address | Number plus IN/OUT direction |
| Endpoint attributes | Control, bulk, interrupt, or isochronous type and synchronization details |
wMaxPacketSize |
Capacity encoding for the selected speed/type |
bInterval |
Scheduling interval interpretation by speed/type |
| Companion fields | Additional capacity information for relevant SuperSpeed endpoints |
When a trace says SET_INTERFACE wIndex=1 wValue=3, locate interface 1, alternate 3—not the third interface descriptor in the file.
Build an alternate-setting map
Create one row for every alternate on the streaming interface:
| Interface | Alternate | Endpoints | Transfer type | Capacity fields | Intended mode |
|---|---|---|---|---|---|
| 1 | 0 | None | — | — | Idle/no stream |
| 1 | 1 | 0x81 |
Isochronous IN | From descriptor | Low-rate mode |
| 1 | 2 | 0x81 |
Isochronous IN | From descriptor | Medium-rate mode |
| 1 | 3 | 0x81 |
Isochronous IN | From descriptor | High-rate mode |
Fill values from raw descriptors. Do not infer mode names solely from alternate number; class-specific descriptors and control negotiation determine the actual format.
Understand periodic bandwidth evidence
Interrupt and isochronous endpoints reserve periodic schedule opportunities. Their effective capacity depends on:
- negotiated USB speed;
- packet-size encoding;
- service interval;
- transactions or bursts permitted by the speed and endpoint descriptors;
- other periodic endpoints on the controller;
- hub and transaction-translator topology;
- host-controller scheduling policy;
- device ability to fill/consume buffers on time.
A single wMaxPacketSize decimal value is not a complete bandwidth calculation across every USB speed. Decode the field according to USB version and endpoint type, and include any companion descriptor that changes burst or bytes-per-interval behavior.
Read SET_INTERFACE as a transition
The control request should be interpreted with surrounding evidence:
- What media or application mode was requested?
- Which interface owns the stream?
- Which alternate did the host select?
- Did the request complete successfully?
- Were old endpoints stopped?
- Did new endpoint traffic begin?
- Did the first error occur immediately or after sustained load?
- Did the host fall back to another alternate?
A stall on SET_INTERFACE suggests the device rejected the selection or mishandled the request. A successful completion followed by no data points to endpoint activation, buffering, driver, or device-state issues. Traffic that starts and later drops points toward sustained scheduling, topology, or buffer health.
UVC-specific comparison
For a camera:
- preserve VideoStreaming descriptors;
- capture probe and commit controls;
- record format, frame, interval, and maximum payload;
- locate the selected alternate;
- inspect isochronous status and payload flow.
If 720p works and 1080p fails, compare more than resolution. Encoding and frame rate may change the payload demand more than pixel count alone. The UVC camera isochronous guide covers frame-level evidence.
USB audio-specific comparison
For audio:
- identify AudioStreaming interface and clock source;
- map alternates to format, channels, subslot size, bit resolution, and endpoint;
- capture sample-rate or clock controls where applicable;
- locate
SET_INTERFACE; - inspect data endpoint and feedback endpoint if present;
- correlate clicks/dropouts with packet status and timing.
An asynchronous audio endpoint may use feedback to control host packet rate. A stream can have valid descriptors and still drift or glitch if feedback values, packet sizing, or buffer management are wrong.
Working-versus-failing test matrix
| Variable | Baseline | Test | Result to record |
|---|---|---|---|
| Quality mode | Lower rate | Higher rate | Negotiated format/interval |
| Topology | Direct port | Hub/dock | Speed and controller path |
| Other traffic | Isolated | Competing camera/audio | First periodic error |
| Host | Host A | Host B | Alternate selection and status |
| Cable | Known-good short | Suspect/long | Speed fallback or transfer health |
| Firmware | Known-good | Candidate | Descriptor/control difference |
Change one variable per run. Start capture before the mode switch and keep the setup request with data traffic.
Distinguish scheduler rejection from stream degradation
Selection rejected
SET_INTERFACEfails;- no target endpoint traffic begins;
- host may retain alternate 0 or try another setting;
- operating system/application reports inability to start.
Selection accepted, stream degraded
SET_INTERFACEsucceeds;- endpoint traffic begins;
- packet status, length, timing, or payload continuity later changes;
- symptom appears as clicks, corrupted frames, or drops.
The remediation differs. Rejection may require descriptor/capacity correction or a lower mode. Degradation requires sustained-load, buffering, topology, and physical-path experiments.
Driver and application behavior
Applications often expose a friendly quality label and hide:
- the final class-control values;
- fallback mode;
- selected alternate;
- device speed;
- actual data rate;
- retry or restart behavior.
Capture the bus transition instead of relying on UI text. Record whether the host chose the exact requested mode or negotiated another one.
Firmware checks
On the device, log:
- received interface and alternate numbers;
- endpoint disable/enable order;
- FIFO allocation;
- DMA start;
- buffer levels;
- first underflow/overflow;
- clock/sample/frame configuration;
- stream stop and reset reason.
Correlate a unique firmware marker with the host trace. A successful control completion followed by no endpoint data may indicate firmware acknowledged before the endpoint was actually ready.
Bus Scope workflow
- Capture enumeration and all alternates.
- Identify the target interface.
- Create the alternate map.
- Capture the class negotiation that chooses the media mode.
- Find
SET_INTERFACE. - Confirm request status.
- Filter to endpoints enabled by that alternate.
- Mark the first transfer error or payload gap.
- compare a lower working mode.
- export the bounded window and setup metadata.
The platform capture guide helps prove the correct USBPcap controller or usbmon bus before analysis.
Common mistakes
Assuming alternate 0 always means failure
Alternate 0 commonly represents idle/no bandwidth. It may be the correct state before or after streaming.
Comparing alternate numbers across interfaces
Always pair interface number and alternate setting.
Reading packet size without speed context
Capacity encoding and scheduling differ by USB speed and endpoint descriptors.
Hiding control traffic
Endpoint errors make more sense when the SET_INTERFACE transition and class negotiation remain visible.
Treating lower quality as a permanent fix
It is a diagnostic experiment. Use the trace to identify whether demand, descriptor contract, topology, or firmware buffering is the boundary.
Questions and answers
What is a USB alternate setting?
It is one of multiple descriptor-defined configurations for the same interface number. The host selects it with SET_INTERFACE, often enabling or changing endpoints.
Why does alternate setting 0 have no endpoints?
Streaming classes commonly use alternate 0 as an idle state that consumes no periodic bandwidth.
Can SET_INTERFACE succeed and streaming still fail?
Yes. Selection can complete while endpoint activation, scheduling, device buffers, clocks, or sustained transfer later fail.
How do I know which alternate is active?
Find the latest successful SET_INTERFACE for the target interface and correlate it with subsequent endpoint traffic.
Is wMaxPacketSize enough to calculate bandwidth?
No. Include USB speed, interval, transfer type, encoded transaction/burst information, companion descriptors, and host scheduling.
When is hardware capture needed?
Use it when host-visible evidence cannot resolve on-wire transactions, precise timing, retries, or electrical behavior.
<!-- multilingual-related-reading:start -->Related guides
Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:
<!-- multilingual-related-reading:end -->