[wdmaudiodev] Re: Debugging USB audio at the hardware level
- From: alex tinsley <cvtrig@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Fri, 18 Sep 2009 23:42:54 -0400
Hi,
The problem may be in that you are trying to use an NEC USB controller and
then matters get worse when trying to use an NEC USB Hub. First of all NEC
is notoriously bad with USB Audio devices, the old Aardvark products used to
state right on their boxes not to use NEC chipsets, this was back in 2002?
I would strongly suggest trying the same setup using anyone else's USB
controller such as TI, Lucent/Agere/LSI, or even VIA.
The other problem that I see here is the USB Hub, there are only a handful
of USB Hubs that properly support the replication of the data streams from
the source for full bandwidth access that USB Audio usually requires.
Griffin made a USB 1.1 hub called a UH-124, this was designed specifically
for USB Audio, it is out of production now. Dr Bott has a 7 port USB Hub
that also worked for USB Audio. In general USB Hubs are not recommended for
USB Audio for the mere fact that it is nearly impossible to determine if the
CM who made it designed it like these mentioned here or cut corners. So it
is safer to avoid them than to try and make them work. If you get it to work
on the one in front of your developer, that may not mean it will work with
everything.
Good luck.
On Fri, Sep 18, 2009 at 2:49 AM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote:
> 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/
>
>
--
When you gotta have it, you gotta have it. Lesson learned from days of
record shopping.
Other related posts:
