Adaptive resampling in gstaudiobasesink.c

Pavel Hofman pavel.hofman at ivitera.com
Sun Oct 18 14:13:01 UTC 2020


Dne 18. 10. 20 v 15:23 Nicolas Dufresne napsal(a):
> 
> 
> Le sam. 17 oct. 2020 17 h 30, <charleslaub at sbcglobal.net 
> <mailto:charleslaub at sbcglobal.net>> a écrit :
> 
> I see, so he was proposing a new version of the callback, that would let 
> app implement their own. To preserve API, this would simply imply adding 
> a second callback. Certainly straight forward, but I think the approach 
> does not cover your (and my) concern about having something to Open > Source directly available.

Thanks for your follow up. IIUC all the existing code in alsasink 
handles only playback positions in the playback ringbuffer, or offers a 
way to control playback speed in the custom callback. But adaptive 
resampling generates new samples, into a new buffer which is passed to 
the sound device. IMO adding another callback would not help, if there 
is no buffer to store the resampled stream.

Perhaps placing another audioresample element into the pipeline BEFORE 
the audio sink  and controlling its momentary resampling rate by some 
messages sent upstream by a GST_AUDIO_BASE_SINK_SLAVE_CUSTOM callback, 
which knows the momentary timing situation and requirements, could be a 
way with minimum changes. That would implement the adaptive resampling 
satisfactorily, IMO.

> 
> I'd rather suggest looking into replacing the resampling code in the 
> sink, using GStreamer resampler or an external one, that is up to the 
> author really. Such contribution will be very welcome, it would with a 
> decent cpu allow easy and professional synchronized playback by anyone.
> 

But IIUC the existing resampling code in the sink does not touch the 
actual sample values and adding the second buffer would mean rewriting 
the audio sink completely, IMO. Way above my understanding of gstreamer 
internals.


Best regards,

Pavel.


More information about the gstreamer-devel mailing list