On Fri, Apr 24, 2020 at 2:21 PM Pavel Hofman <pavel.hofman@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxx/ > > 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
