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

Pavel Hofman pavel.hofman at
Wed Nov 2 07:24:35 UTC 2022

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 
> <> 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 

> 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 
> 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 

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 
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,


More information about the gstreamer-devel mailing list