> I've been thinking about this design as well, but I don't
> see any advantage of this design right now.  But there
> might be.  
> There are some weird devices (like my speakers) where you need a
> device driver because audio devices have two interfaces that need to
> be used together (the Audio Control (i.e. mixer) and Audio Streaming
> (i.e. data) interfaces) so you can't attach them as interface drivers.
> But the device also has some buttons that appear as a HID
> interface.  I've not figured out how to handle this the best
> way yet.

These (and USB modems that comply with the CDC spec) have special
descriptors that indicate how the multiple interfaces are tied 
together.  Your enumerator needs to parse the UNION descriptor
(attached to a COMM-class descriptor) and the (I forget what they
called it)-descriptor, attached to the Audio-class descriptor,
to find how 'interfaces' are associated.  (There are other USB
CDC compliant devices coming, e.g. USB-to-ethernet, USB-to-
DSL, USB-to-cable-modem, USB-to-isdn; so it's worth supporting
that enumeration-model if you can).

The problem is that the USB committee left the notion of functional association
out of the USB spec, and used alt-interface settings to control 
bandwidth.  One is constrained by this in many awkward ways; the
practical consequences are that you need multi-interface devices.

If one is doing multi-port RS-232 devices (as we are) the problem
becomes even nastier, because if one wants to follow the modem spec
to take advantage of vendor (Microsoft) drivers, then one ends up
with two interfaces per RS-232 port.  Interfaces are not hardware
objects, so they don't add much cost, but they do add considerable
complexity to the enumeration logic when one allows them not to be
one-to-one.

--Terry