Hi Martin: You can contact to C-Media Inc. for help. Maybe they can put some kernel print for you to debug. As I know C-Media CM6206's endpoint 6 is the the playback stream endpoint. The USB analyzer say the transfer 10685 has protocol error Data0/1 not found. It's means the HUB don't send data to device. It's a protocol error. You may need also check the upstream of the NEC USB 2.0 hub and check the SSPLIT/CSPLIT transfer. Because the CM6206 is a USB Audio Class 1.0 device. It is full speed USB device. It's should have SSPLIT transfer and CSPLIT transfer in upstream. Another suggestion is replace the NEC USB 2.0 hub use an USB 1.0 hub instead. Or you can try it in Windows Vista. The problem may gone. Because I guess this is a bug in Microsoft USB hub driver. Tzung-Dar Tsai From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Martin Gagnon Sent: Friday, September 18, 2009 4:06 AM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Re: Debugging USB audio at the hardware level Hi, That would imply a timing-related issue. We are only debugging the hardware at this point, using a Release OS with Release drivers, no debugger. Your comment, along with the fact the removing the hub in the device path minimize the symptom, both seem to lead towards a timing issue. But who in the USB stack decides on the Reset event? Is it even in the OS or would the host controller generate the Reset without the OS knowing? Maybe that is why the OS doesn’t report a playback error? Thank you for any insight. Martin Gagnon Matrox Graphics From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of pgruebele Sent: Thursday, September 17, 2009 3:06 PM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Re: Debugging USB audio at the hardware level I had lots of USB problems when I was booting my target into debug mode – even when doing any kernel printing… When booting normally these problems just went away…. From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Martin Gagnon Sent: Thursday, September 17, 2009 3:03 PM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Re: Debugging USB audio at the hardware level Hi Tim, Thank you for your feedback. Yes, endpoint 2 is the endpoint for the audio out data. It appears to be typical of the final OUT transaction to be damaged/corrupted, but before getting that Reset event, we don’t understand why the IN transactions suddenly stops. We tested that the IN transactions work by pressing buttons or transferring audio input data from the device, and indeed we get that data back. The NEC hub is not a constant in this scenario, but it has an impact: if we remove the hub, then the problem appears less frequently. Why the host stops polling with the IN transactions? Who could be generating the Reset event? Thank you, Martin Gagnon Matrox Graphics From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts Sent: Thursday, September 17, 2009 1:27 PM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Re: Debugging USB audio at the hardware level Martin Gagnon wrote: I know this is a software-focused group for audio, but many of you may know a thing or two about USB protocol messages to a USB audio device. Here is the situation, we’re dealing with a C-Media audio device CM6206, using MS usbaudio.sys driver. The C-Media chip is sitting behind a NEC USB2.0 hub that’s connected to a NEC USB2.0 host controller, itself connected to a PLX PCIe switch. Using Windows XP SP3, the driver installs fine, typical audio playback works fine (directsound or wave output). However, when we concurrently enable video and audio, for example playing back a movie in full screen, with no hardware video decoding, we lose audio after “a while”, and can’t get it back. However, the Windows default sounds (for example system beep or logoff sounds) are still working fine. The interval of time before we lose the audio varies with the graphics activity in the system, as well as with various systems of various speeds, so it can take 5mins or it can take 1 day. We tried the C-Media driver as well and got the same symptom. We also tried different USB audio chip manufacturers (including TI) to no avail. So, is endpoint 2 the "sync" endpoint for the audio out data on endpoint 0x86? So we looked at the USB transactions on the USB bus going into the USB audio chip. We note a series of OUT transactions followed by IN transactions, usually containing a “NACK” message. This goes on for as long as the audio plays back fine. Then we get a series of OUT transactions with no corresponding IN transactions, then we get a Reset event. Did you notice that the final OUT transaction is damaged? Is that typical of the captures you've seen? Is the NEC hub a constant in all of this? -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc. ___________________________________________________ 您的生活即時通 - 溝通、娛樂、生活、工作一次搞定! http://messenger.yahoo.com.tw/ ****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.com/