[alsa-devel] Options for ASYNC feedback source in USB-audio gadget (USB OTG)?

[Pavel Hofman]

On Wed, Aug 28, 2019 at 1:17 PM Pavel Hofman <pavhofman at 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
>
> 1) gathering the feedback data from the playback chain
> 2) 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.