All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Mack <daniel@zonque.org>
To: Pierre C <lists@peufeu.com>, alsa-devel@alsa-project.org
Subject: Re: USB Implicit Feedback
Date: Sun, 07 Sep 2014 13:31:25 +0200	[thread overview]
Message-ID: <540C420D.6000202@zonque.org> (raw)
In-Reply-To: <op.xls10oxteorkce@apollo13>

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

  reply	other threads:[~2014-09-07 11:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-06  6:53 USB Implicit Feedback Pierre C
2014-09-06 11:56 ` Daniel Mack
2014-09-07  7:06   ` Pierre C
2014-09-07 11:31     ` Daniel Mack [this message]
2014-09-07 13:30       ` Pierre C

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=540C420D.6000202@zonque.org \
    --to=daniel@zonque.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=lists@peufeu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.