RE: Write takes too long to return

I'm happy to see this issue surface as one that's acknowledged as a bug - we've been trying to ascertain how many of the issues reported from our users and our own testing track to our drivers and devices and kept coming back to Intel Mac laptops as being uniquely problematic in this regard.

First, a couple of questions:

What's the necessity of the keyboard/trackpad being a full-speed device? Last I heard, low-speed input devices are workable.

Also, why the suspend in periods of inactivity? I've found that I have to "wake" the keyboard or trackpad (at times, initial touch isn't registered, even when there are no external devices enumerated.) Are the power savings that significant? - I recognize the spec states that devices on the bus should tolerate this, but it seems to affect the normal use of the laptop.

Those may be rhetorical from Apple's point of view, but hopefully, they're not design decisions based on assumptions that don't take into account the reliability of isoc streaming implementations. The scarcity of ports (2 isn't enough even if they were equally capable, which, apparently they are not) is a challenge when users in the music and audio niche frequently have at least one audio interface + MIDI controller + copy protection dongles, all of which are 1.1 devices that need to be connected concurrently to have a recording/editing system. Apple seems to acknowledge our niche by making Garage Band available as part of the shipping software complement, but expects that most users are going to use FireWire rather than USB, it seems. This brings me to another important point. This thread is the 2nd I've seen on the USB list where an Apple engineer has mentioned USB 2.0 hubs in the context of discussing full-speed isoc audio interfaces. USB 1.1 interfaces (from Digidesign, M-Audio, Line 6 and others) can't provide glitch-free isoc streams connected through 2.0 hubs and multi-TT hub designs are even more problematic. Having endured errata on Intel chipsets in the PC world (915G, 925X. etc.) that render such interfaces unusable, we greeted the Intel partnership with a somewhat jaundiced eye, welcoming more horsepower and more competitive system pricing, but wondering when we'd get blind-sided by another snafu with PCI subsystems that don't play nice with isoc. In fact, the Mac Pro has produced some issues when trying to run proprietary drivers of this nature alongside Class-compliant USB or FireWire drivers, and that led to a recommendation to insert a PCI Express USB host adapter to work around the issue. Since there's no comparable expansion facility in the laptops (don't get me wrong- I love the MacBook) and since there's a dearth of USB ExpressCard/34 adapters for the MacBook Pro, it's wreaking havoc with our support staff in terms of users who want to get the most out of MacBook/MBP in audio applications but can't configure their peripherals without incurring these issues.

I've been involved with Mac music and audio development since 1988, and this is clearly a watershed era in terms of the affordability and power of Macs - please help us by making the systems audio-friendly, which, at least for the present, means USB 1.1-friendly. The user who is doing digital audio recording is going to make selections in terms of power management (like turning it off altogether, certainly not allowing the hard disk to spin down and likely only choosing display sleep) that don't align with the "maximum battery life" slant of most portable computing, so a few extra minutes resulting from suspending the HID module is meaningless in their world. If it could be left to the user to make this selection, all the better. If it can be programmatic on the launch of a recording app, that's acceptable as well.

I was ecstatic to see the Intel mini come with 4 USB ports after enduring the 2-port challenge on the PPC version, but the surfeit of them on the MacBook series remains quite challenging.

Thanks for your efforts in resolving this and please let us know (as we're digging into the bus analyzer phase of our examination at Line 6) what data we can deliver to aid in an effective fix.

Warmest regards,

Bill

Bill Thompson

Manager, QA & Integration Test

Line 6, Inc.

26580 Agoura Rd

Calabasas, CA

>Message: 8

>Date: Fri, 9 Mar 2007 10:59:33 -0700

>From: Rhoads Hollowell <email@hidden>

>Subject: Re: Write takes too long to return

>To: Mark Cookson <email@hidden>

>Cc: email@hidden

>Message-ID: <email@hidden>

>Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes;

>format=flowed

>Hey Mark,

>We have a bug on this already, and we are looking at what we can do

>to fix it without breaking anything else.

>It has to do with the fact that the port in question shares a Full

>Speed controller with the internal keyboard/trackpad, which gets

>suspended when it is not being used to save power.

>You can mitigate this most easily by using a different port.

>You can also insert a High Speed hub, which uses a different controller.

>Other than that, just know that we are aware of the issue and are

>working on a solution.

----------------------------

>Rhoads Hollowell

>USB Software Team

>Apple Inc.