USB Implicit Feedback

USB Implicit Feedback

[Pierre C]

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

Re: USB Implicit Feedback

[Daniel Mack]

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

Re: USB Implicit Feedback

[Pierre C]

>> 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 ;)

Re: USB Implicit Feedback

[Daniel Mack]

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

Re: USB Implicit Feedback

[Pierre C]

> 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.