[alsa-devel] USB Implicit Feedback
Hello !
I'm implementing a USB Audio Class 2 device using a Cortex-M4 with high speed USB. So far it works well, the device is recognized by ALSA, playback, capture, sample rate change, and all controls like volume and mute work. I'm using explicit feedback.
I'd like to use implicit feedback instead, and had some problems...
With implicit feedback, when playback starts, ALSA should start capture automatically (even if there are no applications requesting capture at the moment) to use the number of capture samples as feedback. But it doesn't.
So, I'd like to know :
- Is it actually supported ? - If it is, what descriptors should I use to make it work ?
Thanks for any info, have a nice day !
Pierre
On 09/06/2014 08:53 AM, Pierre C wrote:
I'm implementing a USB Audio Class 2 device using a Cortex-M4 with high speed USB. So far it works well, the device is recognized by ALSA, playback, capture, sample rate change, and all controls like volume and mute work. I'm using explicit feedback.
I'd like to use implicit feedback instead,
Why?
and had some problems...
With implicit feedback, when playback starts, ALSA should start capture automatically (even if there are no applications requesting capture at the moment) to use the number of capture samples as feedback. But it doesn't.
So, I'd like to know :
- Is it actually supported ?
Yes.
- If it is, what descriptors should I use to make it work ?
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
Note, however, that we only implemented implicit feedback mode in the driver because there are devices out there which use such modes. If you're doing the device-side yourself, I'd actually recommend going for explicit feedback, especially if that already works for you. Any particular reason why you want to change that?
Daniel
I'd like to use implicit feedback instead,
Why?
Two reasons :
- 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.
- Implicit feedback would use one less IN endpoint, and that would be useful.
- Is it actually supported ?
Yes.
OK !
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 ?...
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. Do I need to set bAssocTerminal ?
Thanks ;)
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
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 :)
OK. This whole implicit feedback thing seems like a good idea but it smells bad.
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.
Somehow I don't feel like debugging my USB code and ALSA at the same time, while checking both sides against a standard that doesn't exist. Given the complete absence of clear explanation of how it should work in the USB specs, even if the thing ends up working, there will be no guarantee it would be "compliant" to anything...
But as I said - if explicit feedback mode already works for you, I'd stick with it.
I'm going to stick to this advice !... Thanks.
participants (2)
-
Daniel Mack -
Pierre C