Dne 30. 04. 21 v 16:26 Jerome Brunet napsal(a): > From: Ruslan Bilovol <ruslan.bilovol@xxxxxxxxx> > > This adds interface between userspace and feedback endpoint to report real > feedback frequency to the Host. > > Current implementation adds new userspace interface ALSA mixer control > "Capture Pitch 1000000" (similar to aloop driver's "PCM Rate Shift 100000" > mixer control) > > Value in PPM is chosen to have correction value agnostic of the actual HW > rate, which the application is not necessarily dealing with, while still > retaining a good enough precision to allow smooth clock correction on the > playback side, if necessary. > > Similar to sound/usb/endpoint.c, a slow down is allowed up to 25%. This > has no impact on the required bandwidth. Speedup correction has an impact > on the bandwidth reserved for the isochronous endpoint. The default > allowed speedup is 500ppm. This seems to be more than enough but, if > necessary, this is configurable through a module parameter. The reserved > bandwidth is rounded up to the next packet size. > > Usage of this new control is easy to implement in existing userspace tools > like alsaloop from alsa-utils. > > Signed-off-by: Ruslan Bilovol <ruslan.bilovol@xxxxxxxxx> > Signed-off-by: Jerome Brunet <jbrunet@xxxxxxxxxxxx> Hi, the existing patches solve the Host -> Gadget -> capturing application direction, controlling the host playback rate. The other direction (playback app -> gadget -> capturing host) is still paced by the host USB controller. Packet size is pre-calculated in u_audio_start_playback as rate/p_interval https://github.com/pavhofman/linux-rpi/blob/rpi-5.10.y/drivers/usb/gadget/function/u_audio.c#L441 and this fixed value is used for copying the audio data in u_audio_iso_complete https://github.com/pavhofman/linux-rpi/blob/rpi-5.10.y/drivers/usb/gadget/function/u_audio.c#L124 . That means if the gadget has a physical duplex audio device with single clock and runs a duplex operation, the path gadget-> host will not run synchronously with the physical audio device (the host -> gadget has already the feedback control implemented). How about "duplicating" the existing ALSA mixer control "Capture Pitch 1000000" to "Playback Pitch 1000000" and using pitch-adjusted p_srate in the above-linked calculations? That should make the playback side run at the playback pitch requested by gadget userspace, IIUC. For the duplex operation with single clock, the capture pitch value determined by the userspace chain (alsaloop, CamillaDSP, etc.) would be used for setting both the capture and playback pitch controls, making both directions run synchronously. I can prepare patches based on Jerome's patchset should you find this solution acceptable. Thanks a lot, Pavel.
