Mac support regarding VIA VL812

I am waiting on delivery of a Plugable 7 port hub from Amazon. I have a 4 port hub (Uspeed) with the same chipset and I’ve noticed some issues when using it with my Mac. I’ve let Apple know of these issues, but I’m not sure if its on their side, or on the hardware side.

Using the hub I have now (same chipset - Uspeed branded) with 4 items connected I get bandwidth issues:

> 12/26/12 12:06:45.000 PM kernel[0]: USBF: 283590.716 There is not enough USB isochronous bandwidth to allow the device "USB Sound Device " at location 0x14111400 to function in its current configuration (requested 784 bytes for endpoint 0x6 )

Using an old junk USB 2 hub (unpowered) these issues don’t show up. It’s either an error in Apple’s handling of USB, or an error in the hub.

Hi Ryan-

Thanks for posting with a great description of your issue.

I’d love to try and duplicate this issue with a similar sound device: can you share any details about which device(s) you’re using when you’re seeing this error?

Is this a standard USB headset like what is commonly used for Skype/FaceTime, USB speakers, etc? If a model number is available that is particularly helpful.

Again, thanks for posting and we’ll be glad to look into this and try to help isolate where the issue is coming from.

Best wishes-

Jeff Everett
MCITP Enterprise Support Tech
Plugable Technologies

The 4 items connected are a Das Keyboard0, the Das Keyboard’s hub0 (unused), a Griffin iMic audio adapter1 and a 7.1 USB Sound Card 2.

The device having the issue in the log above is the Diamond output.

To clarify, the iMic is being used as my system output and the surround sound is being used solely with programs like Plex or VLC.

Hi Ryan-

Thanks for the details. We don’t have one of the Diamond devices on hand to try to duplicate, but we’ll try with some other usb audio devices we have on hand to try and assist with determining if this is truly device specific or might be a wider, OS related issue.

One additional question: does the Diamond Xtreme work normally when connected directly to your mac? As I understand the issue isn’t present on a direct connection to the Mac, and is only observed when connecting through the hub?

Again, thanks for posting!



Everything works fine when connected directly to the Mac (I assume, haven’t tested that specific setup) but as I mentioned in the first post everything works fine if I use an old unpowered USB 2 hub rather than the Uspeed.

I should be receiving the Plugable hub today to test again soon.

EDIT: Tested with USB port on computer (directly) - it works there

Received Plugable USB3-HUB7-81X.

Plugged in all 4 devices (das keyboard, das keyboard’s hub, iMic, Diamond). Plugged into USB port on Retina MacBook Pro (nothing else is connected to USB).

First message (I’m not worried about this, but I might as well share it):

> 12/28/12 5:24:09.000 PM kernel[0]: USBF: 96708.324 AppleUSBHub[0xffffff803cfcbc00]::ConfigureHub(hub @ 0x14910000) SetFeature(kUSBFeatureDeviceRemoteWakeup) failed. Error 0xe000404f

Set iMic to be the default output. Launched Plex and began playback of a video with 5.1 audio.

Next messages:

> 12/28/12 5:26:22.000 PM kernel[0]: USBF: 96841.407 There is not enough USB isochronous bandwidth to allow the device "USB Sound Device " at location 0x14114000 to function in its current configuration (requested 784 bytes for endpoint 0x6 )

Is it possible that there is an issue with using a USB 3 hub with only USB 2 devices? The reason this is all so strange is because this all does work with the USB 2 hub. Or is there an issue with the VIA chipset’s bandwidth limit?

So as an experiment I plugged the Diamond into the Das Keyboard’s hub (which is USB 2). The Das is still plugged into the Plugable hub (just as the previous setup, with only the 1 change).

It works fine from the Das’ hub. This really leaves me scratching my head at the VIA chip.

Hi Ryan-

Thanks so much for your efforts and posting your nicely detailed findings, it is VERY helpful. Sorry for a delayed response, we have some staff enjoying time with family over the Holidays.

If I could trouble you for one further request I’m confident there will be other details that will be useful in your system profile report. If you’re able to send the .spx as an attachment to a mail, attention Jeff, to we can keep all your system details from being posted publicly. It seems like you’re probably well aware of how to generate the report but please let me know if I can assist.

I’m glad to hear that things are working normally when using the USB 2.0 hub on the keyboard connected via our hub. It’s interesting that the diamond works in this “daisy chain” configuration but not when connected via the USB3-HUB7-81X directly.

With the additional details in your system report I should be able to confirm further details about both your OS and the firmware on the hub, and advise as to whether there might be any firmware updates available or coming soon from via relevant to the issue.

Again, thank you very much for your efforts in testing, finding a workaround, and letting us know what you found.



Email sent. (Sent 2, first one was missing the Diamond.)

As nice as it is that a “work around” is to add a USB 2 hub in the daisy chain it seems rather odd that this issue exists. If the VIA VL812 had bandwidth limitations then I assume that would restrict any downstream devices as well.

I had thought that the bandwidth issues were the result of having 2 USB sound devices on the same hub (iMic and Diamond). As a test I unplugged the iMic and tried again, and yet the console errors continue to trigger and the device does not work.

At this point I assume the bandwidth for this type of device is greater than most devices VIA would have tested with (8 channels at 16 bit, plus the inputs, etc.) and hopefully it is as easy as a firmware update to fix.

After some digging around myself it appears that the Diamond device is made by this OEM:

I can’t figure out which one of these is the item:……

Hi Ryan,

Thanks so much for all these great details. Jeff will keep helping you, but I just wanted to mention quickly that the underlying problem wouldn’t likely be a lack of USB bandwidth – so that error message is a little deceiving – but more likely a problem in reserving space for the isoch schedule (of the 5 underlying USB transfer types, isoch is the one where you can reserve a certain amount of slots). Because the process of setting up an isoch channel and reservations involves every layer of the system – USB host controller hardware, USB stack, hub hardware, device hardware, and device drvier – the problem could lie at any layer. That makes it tricky to track down.

You mentioned an interesting datapoint that the error isn’t generated if you add a USB 2.0 hub in the mix, downstream of the USB 3.0 hub. One of the effect of that is the USB 2.0 hub and the devices off of it would be controlled by the USB 2.0 stack software of the Mac, rather than the USB 3.0 stack software.

That could be pointing to a USB 3.0 / USB 2.0 software stack difference between the two paths. If you happened to have a USB 3.0 Windows machine around, one way to isolate that down would be to see if the Diamond device worked fine there, when directly connected to the USB 3.0 hub.

But, either way, the workaround of connecting through a USB 2.0 hub for the last hop sounds like a good workaround, while we see if we can recreate the issue. Whenever we find an interesting compatibility quirk like this (and there are many right now across different mixes of USB 3.0 hardware and software), we want to track it down to document it if possible.

Thanks again for raising this and helping with it!

Thanks for the technical details Bernie, I always appreciate that. Before posting I had tried to track down the issue in code; some of the pieces are actually open source. If you don’t mind, I’ll try to document what I went through here:

The actual error message (“There is not enough USB isochronous”…) comes from the IOUSBPipe class (CMD+F is our friend):…

This error appears to be triggered when no bandwidth can be allocated of “type” isoc. From there we track down the OpenPipe implementation. We don’t know which type of controller object we’re dealing with (IOUSBControllerV3, IOUSBControllerV2 or just IOUSBController). Those class files are as follows:………

It appears that IOUSBController doesn’t actually implement OpenPipe, and therefore we’re led to V2 or V3 for the implementation. Luckily for us the V3 controller hands off to V2. Again we’re faced with a problem: even though this is a USB 3 hub, is it operating as USB 2 - or rather, is it considered SS? In both cases we make a call to the _commandGate (make note of DoCreateEP), just with different parameters.…

I can’t quite follow that logic but it looks like eventually it calls DoCreateEP (back from IOUSBControllerV2). I assume we’re looking at the case of kUSBIsoc which just eventually calls one of 2 functions:


I can’t find the implementation of either method, and so alas we’re at a stopping point. I haven’t been able to figure out how to enable more detailed logging (getting the output of those USBLog calls would probably be very helpful in tracing this).

Jeff, as far as the spx file I can’t help but notice that there appears to be 2 VIA hubs. One is 3.0 hi-speed, the other is 3.0 super speed. All of the devices are listed under hi-speed, and then under a USB 2 hub within that. Any insight would be nice.

Apparently IOUSBPipe has a V2:…

It looks like IOUSBPipeV2 and IOUSBControllerV3 is where the USB 3 support really kicks in (rather than editing the original class maybe they just keep subclassing or something - I haven’t looked into it deep enough)

On the 2 hub question: There are no 7 port USB 3.0 hub controllers available yet, so every USB 3.0 7 port hub (including ours) uses two 4-port hub controllers attached in series to deliver the 7 ports. If Mac was treating those two differently (e.g. dropping one back into USB 2.0 mode) that would be very interesting! And if it was, you might see different behavior connecting a device to port 1 vs. port 7 of our hub, since they’re on different controllers.

On the Apple software side, I don’t really understand how their stack works, but they appear to have special code to treat USB 2.0 devices on the USB 3.0 bus – USB has this concept and handing at the hardware level, but Apple may be doing more of the work in software (?). Don’t know.

I moved the Diamond from port 4 to port 7. It appears to work.

Here is what System Info is showing:

Lines 2, 4, 9, and 10 are all VIA chips. Is it safe to assume that items 2 and 9 are the “first” chip (apple’s handling of usb 2 vs 3) and items 4 and 10 are the second chip (again, handling usb 2 and 3).

With that said, is it safe to also assume that ports 1-4 are the second chip, and ports 5-7 are the first chip (meaning the first chip is connected directly to the computer, and the second chip is connected to the first chip)?

I’ll see if I can do any more testing of different cases and I’ll compare these results with the Uspeed next.

Some more testing:

Uspeed 4 port:

Sound device works alone

Sound device works with das hub.

Does not work when keyboard is plugged in (+ hub)

Does not work when iMic is plugged in (+ hub)

Plugable 7 port:

Sound device port 1:

Sound device port 7:

Sound device port 1, iMic port 2:
Does not work

Sound device port 6, iMic port 7:
Does not work

Sound device port 1, iMic port 7:

Sound device port 1, keyboard port 2:
Does not work

Sound device port 6, keyboard port 7:
Does not work

Sound device port 6, keyboard port 1:

So it appears my previous thought about bandwidth may be correct, however besides the iMic being an issue, so is my … keyboard?

I’ve also had some issues when waking my computer from sleep. (*Some*) devices on the hub appear not to reconnect (incl keyboards, etc.)

1/2/13 8:39:34.000 PM kernel[0]: USBF: 109320.685 [0xffffff80475bc600] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 1 of Hub at 0x14000000)
1/2/13 8:39:34.000 PM kernel[0]: USBF: 109320.853 AppleUSBHub[0xffffff8058362000]::ConfigureHub(hub @ 0x14900000) SetFeature(kUSBFeatureDeviceRemoteWakeup) failed. Error 0xe000404f
1/2/13 8:39:34.000 PM kernel[0]: USBF: 109321. 3 AppleUSBHub[0xffffff8064c62400]::ConfigureHub(hub @ 0x14910000) SetFeature(kUSBFeatureDeviceRemoteWakeup) failed. Error 0xe000404f
1/2/13 8:39:35.000 PM kernel[0]: USBF: 109321.907 [0xffffff80475bc600] The IOUSBFamily has successfully enumerated the device.
1/2/13 8:39:46.000 PM kernel[0]: USBF: 109332.931 AppleUSBHub[0xffffff8064b0fc00]::ConfigureHub(hub @ 0x14900000) SetFeature(kUSBFeatureDeviceRemoteWakeup) failed. Error 0xe000404f
1/2/13 8:39:46.000 PM kernel[0]: USBF: 109333. 70 AppleUSBHub[0xffffff8058362000]::ConfigureHub(hub @ 0x14910000) SetFeature(kUSBFeatureDeviceRemoteWakeup) failed. Error 0xe000404f
1/2/13 8:39:59.000 PM kernel[0]: USBF: 109345.889 AppleUSBHub[0xffffff8064c59800]::ConfigureHub(hub @ 0x14900000) SetFeature(kUSBFeatureDeviceRemoteWakeup) failed. Error 0xe000404f
1/2/13 8:39:59.000 PM kernel[0]: USBF: 109346. 27 AppleUSBHub[0xffffff8049c12c00]::ConfigureHub(hub @ 0x14910000) SetFeature(kUSBFeatureDeviceRemoteWakeup) failed. Error 0xe000404f

Hi Ryan-

Thanks for continuing to follow up with details.

Sorry about my silence over the past few days- while I don’t have any substantial news I wanted to at least verify that I was able to duplicate similar issues on similar equipment, however haven’t been able to identify any sort of resolution yet. As everyone comes back from the New Years holiday over the next few days I’m hopeful about making more progress.

It’s still unclear if this is something that is entirely a hub/firmware issue, or if some aspects of disabling ports to improve battery life from the OS may be related, or if there are simply conflicts between the devices that more forgiving USB 2 hubs can tolerate that USB 3 isn’t able to.

From reviewing your system profile results it doesn’t appear that any currently available firmware is likely to affect this issue. We’ll be back in touch if/when we’re able to find a resolution or other workarounds.

Best wishes-


Depending on the configuration of the audio devices (how many channels, bitrate, etc) they work and break. It seems clear like there is some type of per-hub limitation with the VIA chips that might be more strict now with USB 3 - or something to that effect.

Has there been any communication or updates from VIA regarding these issues?

Jeff, if you could email me at the address I used for those system profile files that would be great.