On Sun, 15 Nov 2009, Javier Kohen wrote: > 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. Perhaps that is so. But ehci-hcd has no way of knowing whether anything is wrong or not, so to be safe it has to assume that the Clear-TT-Buffer is needed. > 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! Of course. Except for the fact that over time the sound degrades (if you are using an OHCI controller). You mentioned all this before. > 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. Okay, that makes sense. Except for the number of extra requests. In your usbmon logs I counted 50 attempts at that Get-Volume request, which is quite excessive. Three would have been sufficient. > 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. Something definitely has to be done. Not for the device's sake -- presumably the device is handling things just fine, apart from not responding to the request -- but for the sake of the hub. Whenever an error occurs in an async transfer through a Transaction Translator, the TT's buffer is left in an unknown state. The kernel has to clear the TT buffer to make sure it will continue to work properly. > ==== > > 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). You're probably reading the output incorrectly: ffff880072773d80 2958351933 S Ci:1:007:0 s a1 83 0200 0300 0002 2 < ffff880072773d80 2958352055 C Ci:1:007:0 -32 0 The first line shows the request being submitted and sent to the device. The second line shows the end result -- no data, just an error code. The most likely reason for the request to fail is that the device simply doesn't understand or support it. Why _that_ should be, I have no idea. > 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). No, not at all. -32 is not a data value sent by the device; it is an error code indicating that no data was received. > 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." As you surmised, this doesn't apply. Alan Stern -- 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
