When a USB device is hot-plugged while VMware is running, I often see a dialog from the VM instance asking if the device should be attached to the VM or to the host OS. It's quite easy to miss this dialog if you have other applications running or if the VM is in a separate workspace. And until the dialog gets its answer, the device isn't attached to either OS.
If you're not seeing this dialog, it's also possible that VMware has already been configured with a default answer for the device in question. For example, it might automatically be attaching the device to the guest OS running in your VM. Note that this is not normally what you'd want with USB speakers, as VMware already emulates a virtual audio output device for use by guest OS's that funnels audio output through the host OS.
Have a look at your VM settings under "Virtual Machine > USB & Bluetooth Settings…" where you should see a dialog similar to the following:
I expect you should see an entry corresponding to your USB speakers. If so, you should be able to configure how they're handled when hot-plugged from there.
Good news: you don't have any problems with your hardware. Or software, permissions, etc.
The issue is, believe it or not, exactly what the error message says:
the USB hardware ran out of device slots
You're probably under the impression that something like 127 USB devices can be used
with a single controller, since that's what all the marketing material says. But that's actually only true in a single very specific and probably mostly theoretical configuration. USB devices support, at a maximum, five connections in a tiered-star hierarchy. Hubs are not passthrough devices, so they count against this number, as do any internal components which use the USB bus, and any devices which use more than one device profile (even if it's only a single physical connection).
How could I know you don't have a problem with your hardware though?
Why, because I have the same machine, and I was able to reproduce the error!
If the issue seems to be sporadic you're probably running into a couple of other issues too:
Crappy, incompatible chipsets in hubs, since the standard has no enforcement.
Insufficient power: faster USB speeds require more power than slower ones.
If a device has the ability to fall back to a slower speed (rather than error
due to insufficient power), it will do so, taking anything on the same bus with it.
If you don't want to see this error again:
Throw out any USB hubs and cables you are currently using. Dead serious.
Drop the $40-$80 for two to four of these, plus however many of these you need.
Most USB 3 cables should be fine.
Especially considering all the devices you mention are high-speed and not
very error tolerant, you should never rely on bus power, and make sure the (Yep, a wall wart for each hub and device. Exceptions: keyboards, mice, etc.
That last point is especially true on the 11' MBA, which ships with a measly 45W power adapter, and the computer basically needs all of that even with only a moderate CPU load. If you have this cash, consider buying a 60W or 85W adapter.
In practice max, devices/hub connected on a single hub is 2 + another hub.
Always use 4-port hubs, not 7-port. 7-port hubs are just two controllers in a chain.
But you don't know which ports connect to the first hub or the second!
(Without looking in System Profiler.)
If in doubt, prefer the USB port on the logic board (right). There's a remote possibility there's interference in the I/O board. Luckily, that isn't an expensive part.
Follow those steps and I basically guarantee this issue will go away.
Edit: the hardware/kernel development perspective
To answer to the clarification that this is a developer question.
So: The log snippet posted does indicate what I addressed above: too many USB 3.0 devices connected to the root XHCI hub.
(The QS77 chipset supports 4, and there are 2 in use inside the machine.)
To "reset the XHCI controller" (technically its a kernel, not controller, issue):
sudo kextunload -b com.apple.driver.AppleUSBXHCI
sudo kextload -b com.apple.driver.AppleUSBXHCI
however, that's not going to do anything if this is happening with USB 2 devices as well, in which case that its:
sudo kextunload -b com.apple.driver.AppleUSBEHCI
sudo kextload -b com.apple.driver.AppleUSBEHCI
and if its both, well, neither of those.
When I say I can reproduce the issue, I mean that if I overload the XHCI bus like in the log snippet, I get the same error message. And I wasn't assuming necessarily you were using a bad hub — it equally that you might need to get a good one, because the root hub has too many connections.
Beyond that, however, I think we're getting into the realm of a wiki question to the effect of:
How do I debug the kernel and device drivers on Mac OS X?
As thats more the issue, nothing to do with the MacBook Air per se or even necessarily USB.
I might try my hand at writing one (not really my expertise but I've done it a few times) But it'll probably be a few days for that. Meanwhile, take a look at:
man 8 kext_logging and sudo sysctl -w debug.kextlog=0xlogspec
kextstat | grep USB
The IOUSBFamily source.
Best Answer
From VirtualBox usb status bar icon open "USB Settings" and then add your device permanently to VirtualBox.
Then reconnect your device... and that's it.