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

[Arun Raghavan]

On Wed, 2 Nov 2022, at 3:24 AM, Pavel Hofman via gstreamer-devel 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.

Misc note, but I _have_ seen this implemented in-DSP, but that's usually required custom ... everything ...  as it requires passing in timestamps to the driver, and we don't have that in ALSA PCM drivers at least.

That's still going to ultimately running an ASRC, just closer to the final output and possibly using marginally less power.

-- Arun