Write takes too long to return

We’re streaming isoc audio on a MacBook or MacBook Pro and getting occasional dropouts of audio that we’ve traced to being stalled for about 10-20ms in a call to pipe->Write().

 

Also, it appears that the problem only happens on the rearmost USB port on the MacBook, and it only happens after you press a key after you haven’t pressed any keys for a while.

 

And then after pressing a key:

 

  863.429 [5]      AppleUSBUHCI[0x432e000]::RHSuspendPort 2 (RESUME) DONE

  863.429 [3]      AppleUSBUHCI[0x432e000]::RHCheckStatus - Status change for root hub

  863.429 [5]      AppleUSBHubPort[0x457ac00]::PortStatusChangedHandler: port 2 obtained runLock

  863.429 [5]      AppleUSBUHCI[0x432e000]::UIMRootHubStatusChange (Abort: 0, _uhciAvailable: 1)

  863.429 [3]      AppleUSBUHCI[0x432e000]::UIMRootHubStatusChange - no one listening to our changes

  863.430 [1]      ** fUsbPipe->Write Too Long, 9771

  863.430 [5]      AppleUSBUHCI[0x432e000]::GetRootHubPortStatus 2

  863.430 [5]      AppleUSBUHCI[0x432e000]: Port 2: status 95 LINE0 PED CCS

  863.430 [5]      AppleUSBUHCI[0x432e000]: returned status is (103,4)

 

Our log:

  863.430 [1]      ** fUsbPipe->Write Too Long, 9771

 

is timing just how long it took the pipe->Write() call to return, in this case 9771 microseconds.  The numbers range from about 10ms to 20ms.

 

The question is, what can we do to avoid this?  Are we somehow holding a lock that IOUSBFamily needs?  Could we change our order of operations to fix this?  Should we not be requesting an interrupt with every frame (low latency isoc with updateFrequency = 1)?  The fact that it only happens on one MacBook port is very suspicious and makes me worried that we can’t actually fix it on our end, but are there steps we can take to mitigate its effects?

 

Thanks,

Mark

--
Mark Cookson
Software Tech Lead
M-Audio, a part of Avid
225 Locust St.
Hudson, WI 54016