Martin Gagnon wrote: > > > > Yes, endpoint 2 is the endpoint for the audio out data. > I completely asked the wrong question. Endpoint 6 is the audio out data, but what's on the input pipe (endpoint 0x81)? Is that also audio data? Both are 1024-byte packet isochronous with interval=4? > 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. > It should only read input data if someone is streaming data in. Are you running a microphone-using application at the time? > 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? > pgruebele's advice is very good. You should try this without the kernel debugger and see if the results are any different. I, too, have see isochronous transactions fail because of the kernel debugger load. -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc.