[gst-devel] Choppy Audio over UDP

[Marco Ballesio]

Hi,

On Mon, Oct 18, 2010 at 9:03 PM, Wes Miller <wmiller at sdr.com> wrote:

>
> Marco et al,
>
>
> Ok, new pipelines with rtpbin.  These work though I am not sure they are
> completely correct.
>
> SENDER <><><><><><><><><><><><><><><><>
>
> gst-launch-0.10 -v gstrtpbin name=rtpbin \
>         alsasrc do-timestamp=true \
>            ! queue \
>            ! audioresample \
>            ! audioconvert \
>             ! dmaienc_aac outputBufferSize=10000000 outputformat=2 \
>             ! rtpmp4apay         \
>            ! rtpbin.send_rtp_sink_1 \
>         rtpbin.send_rtp_src_1 \
>            ! udpsink port=5002 host=$1  ts-offset=0 name=artpsink \
>         rtpbin.send_rtcp_src_1 \
>            ! udpsink port=5003 host=$1 sync=false async=false
> name=artcpsink \
>         udpsrc port=5007 name=artpsrc \
>            ! rtpbin.recv_rtcp_sink_1
>
>
> RECEIVER <><><><><><><><><><><><><><><>
>
>  gst-launch-0.10  -v gstrtpbin name=rtpbin latency=2000 \
>         udpsrc
>
> caps="application/x-rtp,media=audio,clock-rate=44100,encoding-name=MP4A-LATM,payload=96"
> port=5002 \
>            ! rtpbin.recv_rtp_sink_1 \
>         rtpbin. \
>            ! rtpmp4adepay  \
>            ! decodebin     \
>            ! audioconvert  \
>            ! audioresample \
>            ! alsasink sync=true \
>         udpsrc port=5002   \
>            ! rtpbin.recv_rtcp_sink_1 \
>         rtpbin.send_rtcp_src_1 \
>            ! udpsink port=5003 host=$1 sync=false async=false
>
>
> I am still getting playback that is too fast and choppy.  Sounds like the
> receiver pipe is just playing each packet too fast.  I don't think I'm
> loosing any of the music, it just plays each packet too fast and has a dead
> spot in between them.  Imagine the Moody Blues sung by the Chipmunks with
> hiccups.
>

Ok now I understand what's the issue. If it appears to be between elves or
ogres either you're reading the Lord of Rings or the sample rate differs
between encoder and decoder. You may try and explicitly set the RTP clock in
the receiving pipeline with something lik:

caps="application/x-rtp,media=(string)audio,clock-rate=(int)8000,encoding-name=(string)MPEG4"

Even though these should already be the default values.
Another (more likely) possibility is that the encoder you're using is
working at a default sample rate different from the one of the decoder. You
should thus checker whether any compile/run time options make it possible
for you to use the same values.

Regards


>
> So, first, do I haave the ports mapped correctly?  Am I missing any
> connections between the rtpbin in's and out's?
>
> Secondly, is there a retimesynch trick I can use?  Replacing alsasink with
> fakesink -v tells me that the packets are timestamped and that the
> durations
> match the time between timestamps.
>
> I really intend to replace the mp3 player I am using with a microphone.
>  The
> Leopardboard only has linelevel input so I can't use a mic right now.  If
> passing speech, would I be more likely to hear the speed=up and gaps?  Will
> speex through an rtpxxxpayloader still cause me to need 4k of Caps?
>
> Thanks,
>
> Wes
>
>
>
>
>
>
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/Choppy-Audio-over-UDP-tp2997741p3000742.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101019/9c53eaea/attachment.htm>