alsasrc use-driver-timestamps (was: Selecting alsasrc slave-method: resample not implemented?)

[Pavel Hofman]

Dne 01. 11. 22 v 21:52 Michiel Konstapel via gstreamer-devel napsal(a):
> On Tuesday 01 November 2022 14:11:05 (+01:00), Nicolas Dufresne wrote:
> 
>  > Le mardi 01 novembre 2022 à 10:13 +0000, Michiel Konstapel via 
> gstreamer-devel a
>  > écrit :
>  > > Forgive me for ranting.... These undocumented and
>  > > unimplemented methods/properties make me worry: am I just looking 
> for ghosts?
>  > > Does this all Just Work for everyone and should I just leave things 
> at the
>  > > defaults and move on? Many elements expose properties that seem 
> like they
>  > > involve important tradeoffs to make given a specific use case, but 
> then give
>  > > no information on what the various options do and especially 
> *why/when* you
>  > > would want them. Although they seem important, they are hardly 
> mentioned on
>  > > the mailing list. Source diving sometimes turns up some code or 
> comments, or
>  > > sometimes it just turns out that the exposed knob doesn't even do 
> anything :-/
>  > > Does this mean I have ventured into an area where I'm not supposed 
> to be, or
>  > > is this legitimately missing functionality/documentation?
>  > >
>  > > Not saying that I don't hugely appreciate all the work that's gone into
>  > > gstreamer, and I love hacking on this stuff, but boy does it get 
> frustrating
>  > > at times!
>  >
>  > I believe commercial implementation, were this strongly matter will 
> change a HW
>  > PLL to adjust the HW clock to their system/network clock. This should 
> happen in
>  > combination of slave-method=none on the source and 
> slave-method=custom on the
>  > sink. Be aware that I have never implemented such an advanced 
> solution myself.
>  >
>  > The alternative would be dynamic software resampling, see 
> slave-method=resample
>  > in alsasink, but this has been broken for age, and we don't have 
> anyone working
>  > on it. Audio servers like PipeWire and PulseAudio might already 
> handle this
>  > transparently, that might explain why only alsasrc/sink users reports 
> this.
> 
> 
> Thanks Nicolas!
> 
> Since we're not playing back the audio locally but only streaming it 
> over the network, there are no audio sinks involved. We have multiple 
> sources streaming to a central mixer, so I think it's up to each 
> individual source to sync its audio samples to the NTP system time. We 
> are using wireless USB microphones 
> <https://rode.com/en/microphones/wireless/wirelessgoii> which don't 
> appear to have any controls for finetuning their sampling rates.

Actually while the HW clock pitch control is perfectly viable 
technically, I have never seen a HW audio device which implements it and 
provides control through the driver. In linux I know only about software 
devices with pitch control - alsa loopback and usb audio gadget. But I 
have not seen many things :-).

As a matter of fact my current project would have the technology for 
such a feature (having clock generated by an I2C-adjustable fractional 
divider down from 15GHz), but every non-integer division damages clock 
jitter.

> 
> Does someone on the list have any advice on how to approach this? Should 
> we be using pulsesrc instead of alsasrc? Are there any existing elements 
> that will do the software resampling? I 
> found https://gstreamer-devel.narkive.com/oUoa2zeg/asynchrounous-audio-sample-rate-conversion-with-gstreamer 
> but the thread ends just as it gets interesting ;-)

The best solution would be adding the adaptive resampling to gstreamer 
source/sink, of course :-)

All other solutions will involve other processes which adds to 
complexity and latency.

Do I understand correctly that your input rate is the HW rate, while the 
output rate is clocked by the internal system clock, for streaming over 
network?

Maybe a viable solution could be your USB mic -> snd-usb-audio -> 
alsaloop with adaptive resampling enabled -> snd-aloop -> gstreamer with 
a custom rate plugin. IIUC gstreamer already calculates the required 
resampling ratio, passing it as a parameter to the custom plugin. The 
custom rate plugin would adjust the capturing snd-aloop pitch (via its 
alsa control "Playback Pitch 1000000"), leaving the actual adaptive 
resampling to alsaloop placed before gstreamer.

But when coding that plugin, maybe taking inspiration from alsaloop 
https://github.com/alsa-project/alsa-utils/blob/3b1b6863e7720d870ee34412e08b563605246718/alsaloop/pcmjob.c#L1606 
and coding adaptive resampling directly in that plugin would make more 
sense, with the great benefit of making it finally available for 
everyone :-)

Good luck with your project,

Pavel.