Alan, On Sun, Nov 15, 2009 at 04:24, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > The errors were the lines like these: > > ffff880072773d80 2958351933 S Ci:1:007:0 s a1 83 0200 0300 0002 2 < > ffff880072773d80 2958352055 C Ci:1:007:0 -32 0 > > I don't know what "a1 83 0200 0300 0002" means -- some sort of audio > class-specific request. At any rate, the device didn't recognize or > didn't respond to the request (the -32 error code), and that's the > reason for sending the Clear-TT-Buffer requests. I think it's possible that Clear-TT-Buffer is not needed in this particular case. Possibly nothing is wrong. To test this hypothesis further I booted a pristine git head, plugged the DAC directly into the motherboard's ports and repeated the usbmon exercise. Guess what, the -32 status still occurs, but naturally there are no Clear-TT-Buffer requests -- and it just works! I enabled ALSA debug logs, and it just shows errors getting the current and maximum volume whenever I start alsamixer: ALSA sound/usb/usbaudio.c:1351: setting usb interface 1:1 ALSA sound/usb/usbmixer.c:375: cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0x300, type = 4 ALSA sound/usb/usbmixer.c:740: 3:0: cannot get min/max values for control 2 (id 3) [last two repeated several times...] Look at the req, wValue and wIndex values. Those are the same request parameters as in the logs above. From looking at ALSA's source code in usbmixer.c where it calls the internal get_cur_* it seems the errors are expected. It seems ALSA doesn't trust some mixers 100% so it sends a bunch of extra requests and then looks at all the results. Below I'm leaving a detailed analysis I wrote before I realized that there was a way to have ALSA printing the helpful debug messages. You might find the part about status codes useful, if you still think that something has to be done to handle this error. ==== The following assumes that I'm following the "Universal Serial Bus Device Class Definition for Audio Devices" correctly (http://www.usb.org/developers/devclass_docs/audio10.pdf). >From §5.2.2.4.2 I gather that this is a request to get the maximum volume, which is information that alsamixer would presumably want to request on start up. * GET_MAX = 0x83 according to a table in the appendix. There are also some GET_CUR (0x81) requests. * index 0300 -> unit 3, interface 0, which according to the lsusb output is a feature unit. * value 0200 -> control 2, channel 0, which according to the lsusb output is a volume control. * length 2 -> is the expected length of the volume parameter according to §5.2.2.4.3.2. Now why would this fail, I have no idea. I also don't understand why we don't see the request for this information, just the answer from the device (or I'm reading the usbmon output incorrectly). I'm not having much success parsing the second line, I think. I'm using table 3-1 in §3.7.1.2, according to which -32 (0xe0) indicates an interrupt pending (D7=1), memory contents changed (D6=1), a reserved bit set (D5), and originator being a control interface (D3..0=0). The control interface/unit/something being of index 0 (second byte). If the above were correct, which I doubt, then I think the following paragraph from that section would apply: "The proper response to an interrupt is either a Get Status request (D6=0) or a Get Memory request (D6=1). Issuing these requests to the appropriate originator must clear the Interrupt Pending bit and the Memory Contents Changed bit, if applicable." -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
