[wdmaudiodev] Re: Debugging USB audio at the hardware level
- From: "Martin Gagnon" <mgagnon1@xxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Mon, 21 Sep 2009 12:03:16 -0400
Hi Clemens,
If only the OS can tell the USB controller to generate that Reset event, then
this leads me to my next logical suspect, which are the IN transactions that
suddenly stop. I believe these are IN transactions for the control endpoint,
meant to retrieve button information or else.
Why would they stop happening? Would it make sense to assume that it is also
the host controller driver in the OS that stops these IN transactions before
sending the Reset event isochronous OUT endpoint? Meaning that a problem
happened prior to the IN transactions stopped?
Thanks again for all your feedback, it is appreciated.
Martin
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Clemens Ladisch
Sent: Friday, September 18, 2009 2:49 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Debugging USB audio at the hardware level
Martin Gagnon wrote:
> 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.
The analyzer log indicates that no data was sent in that packet. Host
controllers usually do this only if they are not able to read the data
from memory, and this is probably caused by too much other memory I/O,
in your case the video data.
At which place in the system share the host controller and the video
device a bus, and might that bus' bandwidth be an issue?
In this particular configuration, you might be able to tweak the PCI
latency timers of all involved PCI devices, but this isn't necessarily
a general solution.
> 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?
Only the OS can tell the host controller to generate such events.
> Maybe that is why the OS doesn’t report a playback error?
This looks like a bug in XP's usbaudio.sys.
When an isochronous transfer fails, the driver should just ignore the
error and continue.
When an EHCI host controllers encounters a memory underrun, it sets the
Data Buffer Error bit in the queue head. I don't know how Windows
reports this; it's also possible that the host controller driver decides
to do the reset on its own and that the USB audio driver cannot do
anything about this.
Best regards,
Clemens
******************
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/
Other related posts:
