On Wed, Aug 28, 2019 at 1:17 PM Pavel Hofman pavhofman@gmail.com wrote:
But the feedback EP needs input data. The whole chain behind the virtual capture alsa device defined by the gadget driver is clocked by the playback soundcard. May I ask for your opinions on possible options for
- gathering the feedback data from the playback chain
- passing the gathered samplerate-diff data to the gadget module for
the feedback EP to send to the USB host
IMO some common time frame must be used. E.g. kernel time in nanoseconds.
How about something like this:
1) the core PCM part of alsa driver would keep relative samplerate and present such value in proc/sysfs to userspace. the calculation something like: copied X sample frames in Y kernel nanosecs (for the last e.g. approx. 30 secs ), with nominal samplerate 48kHz. The value would be (10^9 * X frames/Y nanosecs) / 48000 Hz samplerate = e.g. 1.00001
2) the usb gadget code also creates/uses alsa driver, thus measuring/displaying to userspace the same value, e.g. 1.00002 - USB data incoming slightly faster than being consumed by the soundcard
3) the usb gadget would accept some feedback value via procfs/sysfs
4) a userspace daemon could monitor the relative samplerates of the output and of the usb gadget (both values are relative to the same kernel nanosecs clock), could calculate the required adjustment and send proper value to the gadget feedback (in some format). Default async feedback would be "no change", unless received required value from userspace.
Monitoring the average throughput (samplerate relative to kernel clock) could be enabled with a module param for alsa drivers, default off.
The reason for dividing the "kernel-time samplerate" with nominal samplerate is the chain can be resampling (48kHz -> 192kHz), but the relative "deviation" should be the same for any samplerate.
Thanks a lot for any suggestions and comments.
Pavel.