On Wed, Jun 20, 2018 at 9:16 PM, jonsm...@gmail.com <jonsm...@gmail.com> wrote:
> On Wed, Jun 20, 2018 at 11:19 AM Jassi Brar <jassisinghb...@gmail.com> wrote:
>>
>> On Wed, Jun 20, 2018 at 8:32 PM, jonsm...@gmail.com <jonsm...@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Wed, Jun 20, 2018 at 9:36 AM Jassi Brar <jassisinghb...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Feb 13, 2018 at 3:02 PM, Robert Bielik <robert.bie...@dirac.com>
>> >> wrote:
>> >> >> Enabling SOF interrupts will be a big pain :-) Well, enabling the
>> >> >> interrupt itself is a no-brainer, but it'll cause terrible CPU
>> >> >> overload.
>> >> >
>> >> > Oh, I see. Hmm... would it be possible to allow upper levels to config
>> >> > this dynamically ? I.e. for the ALSA subsystem there is no need for the
>> >> > SOF timestamps, whereas for my proposal they would be needed.
>> >> >
>> >> > And what kind of CPU overhead are we talking about ? The IRQs
>> >> > shouldn't come more often than every 125 us, and all that is needed is
>> >> > to take a timestamp value But I'm probably overlooking a lot of stuff...
>> >> >
>> >> I believe we could control data rate precisely enough for the
>> >> feeedback ep to be needed only for compatibility with Windows (Linux
>> >> is already tested to work fine, MacOS is reported to have worked when
>> >> the code was upstreamed.).
>> >
>> >
>> > Right now Windows 10 (all I have checked) refuses to even connect to a
>> > Linux based UAC2 device. It appears to be complaining that no endpoint
>> > supporting USB_ENDPOINT_USAGE_FEEDBACK mode is implement. My five minutes
>> > of poking in the spec implies that implementing this is required for an
>> > endpoint doing USB_ENDPOINT_SYNC_ASYNC. Maybe this is something that can
>> > be faked to the point of allowing Windows to connect to the UAC2 gadget
>> > driver?
>> >
>> Thats what I meant.
>>
>> > The Windows error you get is:
>> > "The driver could not find a feedback endpoint for an asynchronous data
>> > OUT endpoint on device \Device\....."
>> >
>> For OUT, there might be some hoops to jump. Honestly it's been years
>> since I read the spec and got the code to work. I find it tempting to
>> look into Windows 10 as well, but I can't commit to a timeline.
>
> For my application there is no recording HW on the gadget. Maybe a
> quick way to fix this would be to make a flag to say that the gadget
> is output only? And then change the descriptors around?
>
There could be hacks to fool Windows but the right approach is to find
some real uac2 "USB-IN only" device and share the lsusb output. Then
we could kill some descriptor to pretend like that device.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
