alsasrc use-driver-timestamps (was: Selecting alsasrc slave-method: resample not implemented?)
Michiel Konstapel
michiel at aanmelder.nl
Tue Nov 22 09:44:29 UTC 2022
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
More information about the gstreamer-devel
mailing list