usb:gadget:f_uac2: EP OUT is adaptive instead of async

usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Pavel Hofman]

Hi,

The existing UAC2 implementation presents itself as asynchronous 
USB_ENDPOINT_SYNC_ASYNC 
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L276 
+ 
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L285 
.

However:
1) The function does not define any feedback endpoint

2) IMO in reality it is adaptive - the g_audio capture device accepts 
any data passed by the USB host, the USB host is the one which defines 
the data pace.

While Linux and reportedly OSX accept the async EP OUT without explicit 
feedback EP IN, Windows does not.

Simply changing USB_ENDPOINT_SYNC_ASYNC to USB_ENDPOINT_SYNC_ADAPTIVE 
for the FS and HS output endpoints fixes the windows problem and IMO 
corrects the config to reflect real function.

There are multiple projects underway adding the async feedback EP, but 
in the meantime I think the .bmAttributes information should be changed 
as above, making the device usable in Windows for everyone.

Thanks a lot for considering.

Best regards,

Pavel.

Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Greg KH]

On Thu, Feb 06, 2020 at 02:22:47PM +0100, Pavel Hofman wrote:
> Hi,
> 
> The existing UAC2 implementation presents itself as asynchronous
> USB_ENDPOINT_SYNC_ASYNC https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L276
> + https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L285
> .
> 
> However:
> 1) The function does not define any feedback endpoint
> 
> 2) IMO in reality it is adaptive - the g_audio capture device accepts any
> data passed by the USB host, the USB host is the one which defines the data
> pace.
> 
> While Linux and reportedly OSX accept the async EP OUT without explicit
> feedback EP IN, Windows does not.
> 
> Simply changing USB_ENDPOINT_SYNC_ASYNC to USB_ENDPOINT_SYNC_ADAPTIVE for
> the FS and HS output endpoints fixes the windows problem and IMO corrects
> the config to reflect real function.
> 
> There are multiple projects underway adding the async feedback EP, but in
> the meantime I think the .bmAttributes information should be changed as
> above, making the device usable in Windows for everyone.
> 
> Thanks a lot for considering.

Patches work best, can you create them and test and then submit?

thanks,

greg k-h

Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Pavel Hofman]

Dne 06. 02. 20 v 16:41 Greg KH napsal(a):
> On Thu, Feb 06, 2020 at 02:22:47PM +0100, Pavel Hofman wrote:
>> Hi,
>>
>> The existing UAC2 implementation presents itself as asynchronous
>> USB_ENDPOINT_SYNC_ASYNC https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L276
>> + https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L285
>> .
>>
>> However:
>> 1) The function does not define any feedback endpoint
>>
>> 2) IMO in reality it is adaptive - the g_audio capture device accepts any
>> data passed by the USB host, the USB host is the one which defines the data
>> pace.
>>
>> While Linux and reportedly OSX accept the async EP OUT without explicit
>> feedback EP IN, Windows does not.
>>
>> Simply changing USB_ENDPOINT_SYNC_ASYNC to USB_ENDPOINT_SYNC_ADAPTIVE for
>> the FS and HS output endpoints fixes the windows problem and IMO corrects
>> the config to reflect real function.
>>
>> There are multiple projects underway adding the async feedback EP, but in
>> the meantime I think the .bmAttributes information should be changed as
>> above, making the device usable in Windows for everyone.
>>
>> Thanks a lot for considering.
> 
> Patches work best, can you create them and test and then submit?
> 

No problem, I have tested for a few months. I just did not know if you 
would accept such change. I will send the patch then :-)

Thanks,

Pavel.

Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Ruslan Bilovol]

On Thu, Feb 6, 2020 at 3:35 PM Pavel Hofman <pavel.hofman@ivitera.com> wrote:
>
> Hi,
>
> The existing UAC2 implementation presents itself as asynchronous
> USB_ENDPOINT_SYNC_ASYNC
> https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L276
> +
> https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L285
> .
>
> However:
> 1) The function does not define any feedback endpoint
>
> 2) IMO in reality it is adaptive - the g_audio capture device accepts
> any data passed by the USB host, the USB host is the one which defines
> the data pace.
>
> While Linux and reportedly OSX accept the async EP OUT without explicit
> feedback EP IN, Windows does not.
>
> Simply changing USB_ENDPOINT_SYNC_ASYNC to USB_ENDPOINT_SYNC_ADAPTIVE
> for the FS and HS output endpoints fixes the windows problem and IMO
> corrects the config to reflect real function.
>
> There are multiple projects underway adding the async feedback EP, but
> in the meantime I think the .bmAttributes information should be changed
> as above, making the device usable in Windows for everyone.

Are you working on async feedback EP implementation? I'm interested in that
feature and I can implement it soon but do not want to do double work
if somebody
is already working on it and will send to the community soon

Thanks,
Ruslan

>
> Thanks a lot for considering.
>
> Best regards,
>
> Pavel.

Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Pavel Hofman]

Hi Ruslan,

Dne 11. 02. 20 v 17:10 Ruslan Bilovol napsal(a):
> On Thu, Feb 6, 2020 at 3:35 PM Pavel Hofman <pavel.hofman@ivitera.com> wrote:
>>
>> Hi,
>>
>> The existing UAC2 implementation presents itself as asynchronous
>> USB_ENDPOINT_SYNC_ASYNC
>> https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L276
>> +
>> https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L285
>> .
>>
>> However:
>> 1) The function does not define any feedback endpoint
>>
>> 2) IMO in reality it is adaptive - the g_audio capture device accepts
>> any data passed by the USB host, the USB host is the one which defines
>> the data pace.
>>
>> While Linux and reportedly OSX accept the async EP OUT without explicit
>> feedback EP IN, Windows does not.
>>
>> Simply changing USB_ENDPOINT_SYNC_ASYNC to USB_ENDPOINT_SYNC_ADAPTIVE
>> for the FS and HS output endpoints fixes the windows problem and IMO
>> corrects the config to reflect real function.
>>
>> There are multiple projects underway adding the async feedback EP, but
>> in the meantime I think the .bmAttributes information should be changed
>> as above, making the device usable in Windows for everyone.
> 
> Are you working on async feedback EP implementation? I'm interested in that
> feature and I can implement it soon but do not want to do double work
> if somebody
> is already working on it and will send to the community soon

I would be happy if you focused on the feedback. I want to solve the
g_audio usability somehow first
https://lore.kernel.org/linux-usb/df2eeff0-ca9c-35f9-2e72-8426b2cf72c9@ivitera.com/
as it would allow easy usage of the existing adaptive gadget version.

The feedback - I have been shown a simple implementation which is not
public and is not using the g_audio alsa device on the other side.

IMO the key issue is designing the async feedback to accept feedback
values from userspace as well as from any third-party kernel module. Why
userspace? The stream provided by the g_audio capture device  can be
output to a real master-clock alsa device (e.g. after synchronous
resampling), be sent by network to some master-clock device, many other
options possible. Any master-clock output device/ userspace sink should
be able to provide data for calculating proper up-to-date feedback value
for the slaved UAC2 gadget.

I have done a few trials with master alsa output device -

https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg.html#post5909816


https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg.html#post5910911

Details for alsa-lib are discussed in
https://www.spinics.net/lists/alsa-devel/msg96781.html


This is a solution I need - syncing the UAC2 gadget to master clock of
real alsa soundcard . But again - I think the solution should be
flexible to support any source of feedback information, be it in kernel
or from userspace.

Perhpas we should open a new thread on the async feedback, IMO it will
be long :-)

Thanks,

Pavel.

Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Pavel Hofman]

Dne 11. 02. 20 v 20:02 Pavel Hofman napsal(a):
> Hi Ruslan,
> 
> Dne 11. 02. 20 v 17:10 Ruslan Bilovol napsal(a):
>> On Thu, Feb 6, 2020 at 3:35 PM Pavel Hofman <pavel.hofman@ivitera.com> wrote:
>>>
>>> .
>>
>> Are you working on async feedback EP implementation? I'm interested in that
>> feature and I can implement it soon but do not want to do double work
>> if somebody
>> is already working on it and will send to the community soon
> 
> I would be happy if you focused on the feedback. I want to solve the
> g_audio usability somehow first
> https://lore.kernel.org/linux-usb/df2eeff0-ca9c-35f9-2e72-8426b2cf72c9@ivitera.com/
> as it would allow easy usage of the existing adaptive gadget version.
> 
> The feedback - I have been shown a simple implementation which is not
> public and is not using the g_audio alsa device on the other side.
> 
> IMO the key issue is designing the async feedback to accept feedback
> values from userspace as well as from any third-party kernel module. Why
> userspace? The stream provided by the g_audio capture device  can be
> output to a real master-clock alsa device (e.g. after synchronous
> resampling), be sent by network to some master-clock device, many other
> options possible. Any master-clock output device/ userspace sink should
> be able to provide data for calculating proper up-to-date feedback value
> for the slaved UAC2 gadget.
> 
> I have done a few trials with master alsa output device -
> 
> https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg.html#post5909816
> 
> 
> https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg.html#post5910911
> 
> Details for alsa-lib are discussed in
> https://www.spinics.net/lists/alsa-devel/msg96781.html
> 
> 
> This is a solution I need - syncing the UAC2 gadget to master clock of
> real alsa soundcard . But again - I think the solution should be
> flexible to support any source of feedback information, be it in kernel
> or from userspace.
> 

Hi, please can we resume this discussion about the feedback endpoint?

Meanwhile a simple method described in
https://www.aktives-hoeren.de/viewtopic.php?p=137829&sid=0d6cd50e0f58618da33621c62e412ada#p137829
for obtaining required rate shift from /proc/asound/.../status to keep
the master side buffer optimally filled was tested. That could be one
source for the rate shift, to be passed to the driver. Perhaps a control
element like the "PCM Rate Shift" of the snd-aloop driver could be used.


Thanks a lot,

Pavel.

Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Ruslan Bilovol]

On Fri, Apr 24, 2020 at 2:21 PM Pavel Hofman <pavel.hofman@ivitera.com> wrote:
>
>
>
> Dne 11. 02. 20 v 20:02 Pavel Hofman napsal(a):
> > Hi Ruslan,
> >
> > Dne 11. 02. 20 v 17:10 Ruslan Bilovol napsal(a):
> >> On Thu, Feb 6, 2020 at 3:35 PM Pavel Hofman <pavel.hofman@ivitera.com> wrote:
> >>>
> >>> .
> >>
> >> Are you working on async feedback EP implementation? I'm interested in that
> >> feature and I can implement it soon but do not want to do double work
> >> if somebody
> >> is already working on it and will send to the community soon
> >
> > I would be happy if you focused on the feedback. I want to solve the
> > g_audio usability somehow first
> > https://lore.kernel.org/linux-usb/df2eeff0-ca9c-35f9-2e72-8426b2cf72c9@ivitera.com/
> > as it would allow easy usage of the existing adaptive gadget version.
> >
> > The feedback - I have been shown a simple implementation which is not
> > public and is not using the g_audio alsa device on the other side.
> >
> > IMO the key issue is designing the async feedback to accept feedback
> > values from userspace as well as from any third-party kernel module. Why
> > userspace? The stream provided by the g_audio capture device  can be
> > output to a real master-clock alsa device (e.g. after synchronous
> > resampling), be sent by network to some master-clock device, many other
> > options possible. Any master-clock output device/ userspace sink should
> > be able to provide data for calculating proper up-to-date feedback value
> > for the slaved UAC2 gadget.
> >
> > I have done a few trials with master alsa output device -
> >
> > https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg.html#post5909816
> >
> >
> > https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg.html#post5910911
> >
> > Details for alsa-lib are discussed in
> > https://www.spinics.net/lists/alsa-devel/msg96781.html
> >
> >
> > This is a solution I need - syncing the UAC2 gadget to master clock of
> > real alsa soundcard . But again - I think the solution should be
> > flexible to support any source of feedback information, be it in kernel
> > or from userspace.
> >
>
> Hi, please can we resume this discussion about the feedback endpoint?
>
> Meanwhile a simple method described in
> https://www.aktives-hoeren.de/viewtopic.php?p=137829&sid=0d6cd50e0f58618da33621c62e412ada#p137829
> for obtaining required rate shift from /proc/asound/.../status to keep
> the master side buffer optimally filled was tested. That could be one
> source for the rate shift, to be passed to the driver. Perhaps a control
> element like the "PCM Rate Shift" of the snd-aloop driver could be used.

I worked on this during last moths and implemented feedback endpoint
and other improvements to UAC2 driver.
Currently it's under testing, I do expect to submit patches to community soon.

I used the same idea with "PCM Rate Shift" control to make it work with
existing alsaloop tool, but the in this case I do think it's better to expose
frequency directly to the control

Anyway, let'l look at the patches

Thanks,
Ruslan

Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Pavel Hofman]

Dne 24. 04. 20 v 14:34 Ruslan Bilovol napsal(a):
> 
> I worked on this during last moths and implemented feedback endpoint
> and other improvements to UAC2 driver.
> Currently it's under testing, I do expect to submit patches to community soon.

That is amazing, thank you.

> 
> I used the same idea with "PCM Rate Shift" control to make it work with
> existing alsaloop tool, but the in this case I do think it's better to expose
> frequency directly to the control

I agree. Nevertheless compatibility with alsaloop would be quite useful.
 E.g. the gadget could just implement a simple loopback from gaudio ->
some alsa plugins chain -> one or more output soundcards to offer simple
features not available readily in other OSes (route, multi, etc). With
alsaloop such configuration would be very simple. Perhaps making both
relative and absolute controls available?

Thank you for your work.

Regards,

Pavel.

Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Pavel Hofman]

Dne 22. 07. 20 v 17:25 harrison conroy napsal(a):
> Hi Ruslan, 
> 
> I am working on a project that involves using an RPi 4 as a USB Gadget
> and we have run into the feedback endpoint issue causing Windows 10 to
> not recognize it as a USB audio device. Do you have any updates on this
> patch for the community? Any help would be greatly appreciated.

As a temporary workaround you can change the EP OUT type from
USB_ENDPOINT_SYNC_ASYNC to USB_ENDPOINT_SYNC_ADAPTIVE.

Or you can add implicit feedback flag to the EP IN. Win10 should handle
implicit feedback OK, unlike Win7. Unfortunately linux still requires an
explicit quirk for the implicit feedback
https://www.spinics.net/lists/alsa-devel/msg111824.html . Yet it is
still a workaround because IMO the existing EP IN is in fact not async
but adaptive, clocked by the USB frames.

Pavel.

Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async

[Ruslan Bilovol]

On Sat, Jul 25, 2020 at 1:24 PM Pavel Hofman <pavel.hofman@ivitera.com> wrote:
>
>
> Dne 22. 07. 20 v 17:25 harrison conroy napsal(a):
> > Hi Ruslan,
> >
> > I am working on a project that involves using an RPi 4 as a USB Gadget
> > and we have run into the feedback endpoint issue causing Windows 10 to
> > not recognize it as a USB audio device. Do you have any updates on this
> > patch for the community? Any help would be greatly appreciated.
>
> As a temporary workaround you can change the EP OUT type from
> USB_ENDPOINT_SYNC_ASYNC to USB_ENDPOINT_SYNC_ADAPTIVE.
>
> Or you can add implicit feedback flag to the EP IN. Win10 should handle
> implicit feedback OK, unlike Win7. Unfortunately linux still requires an
> explicit quirk for the implicit feedback
> https://www.spinics.net/lists/alsa-devel/msg111824.html . Yet it is
> still a workaround because IMO the existing EP IN is in fact not async
> but adaptive, clocked by the USB frames.
>

There is a commit which I've sent earlier this month which is a part
of Win10 enumeration solution:
https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git/commit/?h=next&id=a9cf8715180b18c62addbfe6f6267b8101903119

For the rest of the solution (feedback endpoint implementation) I'm
refreshing patches on top of this, and expect to submit them very soon

Thanks,
Ruslan