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

[Michiel Konstapel]

On 02-11-2022 08:24, Pavel Hofman wrote:
> 
> 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.

Thanks for the responses everyone, and apologies for being so late to 
reply - busy going into the field with this stuff!

For now I've settled on using the NTP-synced monotonic SystemClock as 
the pipeline clock on both the sender and the receiver, with alsasrc 
provide-clock=false (and use-driver-timestamps left at the default, so I 
think that's "true") and that appears to be working OK: good audio 
quality (no crackling) and no timing issues after several hours of 
streaming.

Kind regards,
Michiel