Hi,
On 09/07/2014 09:06 AM, Pierre C wrote:
- The Apple app notes seem to say it's the best way to do things, and I'd
like it to also work on Macs. But I'm not married to Apple, and it seems Macs also support explicit feedback, so this isn't a very important point.
Explicit feedback is much more common than anything else, and I haven't yet seen a standard compliant device with implicit feedback in the wild. And more common means more test coverage :)
- Implicit feedback would use one less IN endpoint, and that would be
useful.
Yes, but it will always cause traffic in both directions, even if only one is actually used. Unless you're in full-duplex mode, you'll waste 50% of the bandwidth.
The usage mask of bmAttributes of the endpoint should be USB_ENDPOINT_USAGE_IMPLICIT_FB, along with some other constraints. See set_sync_endpoint() in sound/usb/pcm.c
I have read this source code before but I'm not sure what the second parameter of "get_endpoint(alts, 1)" really means, does it imply that an altsetting has to have 2 endpoints and it takes the second one, but in which order ? order of definition in descriptors, endpoint number ?...
That's the index of the endpoint in the given alt interface.
But is it bmAttributes in the playback endpoint descriptor, or its buddy capture endpoint ? The USB docs are quite vague and I see several possible interpretations ... Does the playback AudioStreaming descriptor need to have 1 endpoint, or 2 ?... I've tried various combinations with the latest stable linux kernel, none worked.
It's been a while since I looked into this, but when I implemented the code in the first place, I had no standard compliant device to test with, so I had to force the driver into implicit mode with a quirk. I'd recommend adding printk() to the driver and trace the calls and see how they parse the descriptors.
But as I said - if explicit feedback mode already works for you, I'd stick with it.
Best regards, Daniel