device filtering support

[Vitali Lovich]

On Feb 5, 2012, at 5:25 AM, Pete Batard wrote:

> On 2012.02.05 01:32, Xiaofan Chen wrote:
>>>>> OK. Disruptive, in the way I understand Travis' concern, is:
>>>>> - libusbx (or non libusbx) app 1 is doing isochronous or bandwidth
>>>>> heavy transfers on the bus
>>>>> - libusbx app 2 is either launched or does something (open) that
>>>>> produces an enum. With the current Windows enum process, this
>>>>> results in hubs being queried and potential packet dropped for app 1.
>> 
>> It is worse than you think it is.
>> 
>> Take note app1 and app2 operate on different device.
> 
> I think that was implied. Having 2 apps operate on the same device is usually bad news (and libsub(x) won't let you do it unless you unclaim and stuff).
> 
>> And it is not
>> only isochronous transfer, it can affect other transfer type like
>> bulk transfer as well.
> 
> Also implied by "or bandwidth heavy"
Bulk & control transfers aren't a problem - the usb hardware will retry lost packets on your behalf & applications must handle transfer failures gracefully.  Isochronous would be the only potential problem given that it implies strict timing & bandwidth requirements, except it's not since the USB hardware automatically reserves bandwidth + provides latency guarantees.