Asynchrounous Audio Sample Rate Conversion with gstreamer

[Sebastian Dröge]

On Fr, 2016-04-29 at 21:11 +0200, Maik Scholz wrote:
> Hi, 
> 
> in some use cases (broadcast digital radio or IP radio), the
> transmitter is sending an audio stream with a nominal sampling rate
> (e.g. 48kHz).
> When a receiver, expecting 48KHz, wants to play these samples on a
> local sound sink, then there is always the problem, that the
> transmitter clock slightly differs from the receiver clock.
> For that issue, I need an asynchronous sampling rate converter!
> 
> Is this possible the available gstreamer plugins?
> Do audioresample support asynchronous clocks?

audioresample not, it's not really audioresample's job to do this kind
of work (but in your case you can use audioresample to resample the
audio as you know the ratio between sender and receiver rate).

This is something that can be implemented on various layers, e.g. with
RTP this would happen based on the RTP timestamps and arrival times
inside the rtpjitterbuffer. You don't have any timestamps inside the
stream so that won't do it.

In your case you would have to implement something similar somewhere
downstream of the tcpserversrc. Something that correlates the amount of
data received per time unit with the duration of that time unit and
then extrapolates the relative rate difference between the server and
receiver clock, and then accordingly timestamps the media, or directly
resamples the media (for which you can again use audioresample here).
One main problem in your case is that you use TCP, and due to all the
buffering that happens in TCP you will have it harder to calculate this
than with UDP. And as you don't have timestamps inside the stream, you
will have to assume that your media is continuous which might also not
be true.


And then (if you don't resample anywhere but just adjust timestamps),
it's the job of the audio sink in the end of make up for the difference
between timestamps and actual samples received. It will be default just
"skip" (skew) but you can configure it also to resample, this can be
done with the slave-method property on all audio sinks.
However the resampling that is currently implemented there is very
minimal and audioresample will give you better quality, but that's
something that should be fixed.


Does that answer your question? There's no standard solution for this
(as your streaming protocol is not and has many use case specific
assumptions) and you have to implement something yourself with the help
of existing GStreamer code.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160501/b1529079/attachment.sig>