[wdmaudiodev] Re: Debugging USB audio at the hardware level
- From: Tim Roberts <timr@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Thu, 17 Sep 2009 12:56:40 -0700
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.
Other related posts:
