device filtering support

[Vitali Lovich]

On Feb 4, 2012, at 6:02 PM, Xiaofan Chen wrote:

> On Sun, Feb 5, 2012 at 9:45 AM, Michael Plante <michael.plante at gmail.com> wrote:
>> Xiaofan Chen wrote:
>>>> It is worse than you think it is.
>>>> 
>>>> Take note app1 and app2 operate on different device. And it is not
>>>> only isochronous transfer, it can affect other transfer type like
>>>> bulk transfer as well.
>> 
>> Yes, I realize that, and bulk transfers are retried anyway.  My point is
>> pretty general.  One thing I did not consider is time-shared/multiuser
>> machines, but users do not usually hotplug on those, or even have physical
>> access.
>> 
>>>> app1 can be a non-libusbx application operating on a device which
>>>> the innocent Joe user think that app2 should have nothing to do with.
>> 
>> Irrelevant.  If "Joe user" cannot put two and two together that he just
>> plugged something in and his video started lagging and "oh I guess I
>> shouldn't do that again", he should go buy a typewriter.
> 
> No he did not plugged anything. He is listening to music using
> a USB Audio Device (USB Audio Speaker). And whenever he
> runs another application (which depends on libusbx and operate on
> a generic USB device) and suddenly finds that the audio get
> distorted.
Isochronous traffic has a guaranteed portion of USB bandwidth allocated + have guarantees on latency.  Bulk & control transfers cannot interfere with that.  So you doing any other USB traffic would not cause any interference as described.  I find it highly unlikely given how USB works that we could cause issues with other applications.  USB applications already have to be robust in the case of increased traffic or interleaved traffic (hence the reason only 1 claim of an interface is allowed at the same time). 
> 
> The user is smarter than the average Joe users, so he
> moves his USB Audio device to a different root hub port,
> still the problem exists. He gets annoyed.
> 
> I know this example may not be a very good one. But you
> get the idea.
Not really given the above explanation of the guarantees for isochronous transfers.
> 
>>>> So do you think this is just plain "excessive" and thus only need
>>>> "optimization" or it "break things" and need "rethink this whole thing"?
>> 
>> I would argue that the cure is worse than the disease.  I think that if/when
>> this happens, the traffic is in fact excessive, and that while the
>> optimization Pete suggests might solve the problem, it creates bigger
>> problems.  While this excessiveness breaks things, the proper solution is
>> "don't do that".  Sort of like learning not to pull the power plug from your
>> computer while it's running.
> 
> I agree with you that Pete' cure is worse than the disease. But if we go
> with the approach Travis is using in libusb-win32 and libusbK, app2 will
> not disturb app1 at all.
> 
> On the other hand, I understand the desire to follow the Linux libusb's
> idea of "query all USB device for information". In that case, libusbx
> can not use the approach of libusbK. I was hoping Vitali's filter approach
> can help to make things better.
I fail to see anyone actually demonstrating that there's a problem here as opposed to a hand-wavy theoretical issue.  Until there's a demonstrable issue here, there is no point in trying to over-architect a solution to a theoretical problem, especially one that appears to be poorly understood.

We've already strayed way beyond the original purpose of the thread which is to discuss device filtering to make the API easier to use; somehow got hi-jacked into some weird discussion about theoretical issues on Windows.