https://bugzilla.kernel.org/show_bug.cgi?id=219111 --- Comment #55 from Alan Stern (stern@xxxxxxxxxxxxxxxxxxx) --- The really important thing is bNumConfigurations. If it is set to 1 then the device doesn't make config 2 available, but if it is set to 2 then the device does make config 2 available (even if the computer decides to use config 1). The configuration descriptor includes four interfaces. Interface 0 is the audio control interface; it describes two USB terminals (one in, one out) and two audio terminals (one in, one out). It also says that the input terminals each have 2 channels (regular stereo). Interfaces 1 and 2 are for audio streaming. Interface 1 is the USB-out connection; it runs at 48000 Hz with 24-bit samples, it can be synchronized to a clock on the device, and it can also operate in a vendor-specific way. Interface 2 is the USB-in connection; it also runs at 48000 Hz with 24-bit samples and it also has a vendor-specific alternate setting. Interface 3 is for MIDI. As far as I can see, you aren't using it. The packet capture shows the computer issuing a few vendor-specific requests. I have no way to know what they mean, but they involve getting data from the device, not sending data to the device. So they probably don't affect the way the device operates. The thing we really need to know is how the Windows driver tells the device to switch to configuration 2. I haven't seen anything in the packet captures that show how it does this. (However, the most recent capture shows that at the 361-second mark, the computer deconfigures the device and the sets it back to configuration 1. I can't tell why that happened.) Or maybe the Windows driver uses the vendor-specific alternate settings rather than the standard USB audio class settings. The packet captures don't show the computer telling the device which alternate setting to use. This must happen, because the default setting uses no bandwidth and transfers no audio data, but it doesn't show up in the packet captures. (It does show up in the usbmon traces.) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
