On 1/20/08, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > Sorry ... I thought he had posted lcpci showing a NEC controller
> > > with EHCI *and* OHCI.
> >
> > It is a NEC controller with both. But I have 1.0 hub plugged in with
> > three 1.0 devices in it. The 1.0  hub causes the OHCI controller in
> > the NEC to be used.
> >
> > I have had even worse luck trying to get three USB audio devices
> > working on 2.0. That NEC chip is a single-TT EHCI implementation.
>
> Actually it's a NEC chip with a zero-TT implementation.  ;)
>
> I forget why our high speed root hubs lie about having a TT.
> They probably don't need to do that, except for the ones that
> don't have companion controllers.  Like the silicon using the
> IP from ARC, Mentor, and so on.
>
>
> > USB plug and play sure doesn't work very well with three audio
> > devices.
>
> I didn't catch those details.  What do you mean by that?  Do
> they not enumerate?  Do their drivers not get loaded?  Is some
> userspace setup missing?  Or do the drivers misbehave?

I tried this setup a while ago on a single-TT 2.0 hub. It would seem
that 4.2Mb of audio data wouldn't fill up a 480Mb channel. But that's
when I learned about single-TT hubs, the audio would drop out because
of scheduling problems. I tried some of the scheduling patches which
helped but didn't fix it 100%. There's a thread about it in archives
somewhere. I think you were helping, it was about nine months ago.

Someone suggested that I switch to a 1.0 hub. I've been using the 1.0
for the last nine months. The only problem is that it drops all of the
devices about once every 20 hours.

I'll giving up on building a new kernel for the slug, there are way
too many manual steps involved.
http://www.nslu2-linux.org/wiki/Debian/BuildImage
It's just taking too long. I'll ask on the NSLU2 ground maybe someone
will point me at an automated x86 build environment.

> Disconnecting isn't what I'd call a PNP issue.

I think of PNP as being able to plug in three 1.0 audio devices and
have it work on the first try without going through three different
hubs (1.0, 2.0 single-tt, 2.0 multi-tt) to find one that works
reliably.

>
>
> > I'd like to be able to use six with the NSLU2, it has enough
> > CPU power. But I can't even get three to work reliably.
>
> It might not have enough DMA capacity; there are other issues
> that can affect system capability...

With USB 2.0 It can do 22MB/sec to the disk cache and 6MB/sec to the
disk. DMA seems to be ok. This is on the same controller. Disk is only
very lightly used when playing music. I'm 58% idle on the CPU with
three streams playing. Half of the memory is in use, the other half is
cache.

>
>
> > So if I get a 2.0 hub with multi-TT, and plug it into the NEC chip
> > whose EHCI hub is only single-TT,  does this have a chance of working?
>
> It has a chance of working, yes.  Only one TT is ever involved
> with a given full or low speed device, and it'll be found in
> the nearest upstream hub running at full speed.  While you're
> connecting to the root hub, the nearest such hub is OHCI and
> no TT matters.  If you connect a multi-TT hub, that's what will
> matter.
>
>
> > What I need are 2.0 audio devices but they don't appear to exist.
>
> Some exist, but they're not common.  ISTR they were geared for
> sound card replacement -- and thus needed lots of channels.  Normally
> audio doesn't need much bandwidth, so there's no point in paying
> any of the extra costs implied by high speed support.
>
> - Dave
>


-- 
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to