[wdmaudiodev] Re: Debugging USB audio at the hardware level
- From: Clemens Ladisch <clemens@xxxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Fri, 18 Sep 2009 08:49:20 +0200
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:
