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. Thanks a lot, Pavel.
