[wdmaudiodev] Re: Debugging USB audio at the hardware level

  • From: "pgruebele" <pgruebele@xxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 17 Sep 2009 15:05:47 -0400

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.

Other related posts: