udpsink to udpsrc choppy - stacato sine wave

[Wes Miller]

I have written simple pipes to encode an audiotestsrc sine wave into aac then mp4a payloadit and send it over the network to a matching udpsik, depay, decode and pulsesink.

The sound comes out choppy, uniformly spaced, but chopped into beeps.  Sounds a lot like Morse code but it's all E's.

Here are the pipes: (they are on the same PC but I've also tried it between 2 computers)

Source

      gst-launch   audiotestsrc \
           ! audio/x-raw-int, rate=44100, channels=2, endianness=1234, width=16, depth=16 \
           ! ffenc_aac \
           ! rtpmp4apay \
           ! udpsink host=10.253.5.151 port=5002

and Sink

      gst-launch-0.10  -v -e udpsrc port=5002
             caps=application/x-rtp,media=audio,clock-rate=90000, encoding-name=MP4A-LATM,cpresent=0, \
             config=NULL,payload=96,ssrc=3574762534,clock-base=2565233379,seqnum-base=29343  \
           ! gstrtpjitterbuffer \
           ! rtpmp4adepay \
           ! audio/mpeg,channels=2,rate=44100,mpegversion=4,stream-format=raw,codec_data=\(buffer\)1210
           ! ffdec_aac
           ! pulsesink

NOTE:  Actually sounds better without the jitter buffer.

I tried modifying the source pipe to do ... ffenc-aac ! ffdec_aac ! pulsesink.    Sound great.  I'm pretty sure that means the network or network elements are my problem.

So, anyone have suggestions for getting better sound quality across the net?  I know it's possible; other programs do it every day.

ps.  I have also coded the receiver in C, with and without gstrtpbin.  Does not help.

Warmly,

Wers


     

[Wim Taymans]

On Fri, 2010-11-19 at 07:08 -0800, Wes Miller wrote:
> I have written simple pipes to encode an audiotestsrc sine wave into aac then
> mp4a payloadit and send it over the network to a matching udpsik, depay,
> decode and pulsesink.
>
> The sound comes out choppy, uniformly spaced, but chopped into beeps.
> Sounds a lot like Morse code but it's all E's.

The clock rate on the receiver looks wrong. You should copy and paste
the caps from the sender to the receiver without changing them. If you
change them, the receiver has no idea what kind of data it is dealing
with and it will not work.

Wim

>
> Here are the pipes: (they are on the same PC but I've also tried it between
> 2 computers)
>
> Source
>
>       gst-launch   audiotestsrc \
>            ! audio/x-raw-int, rate=44100, channels=2, endianness=1234,
> width=16, depth=16 \
>            ! ffenc_aac \
>            ! rtpmp4apay \
>            ! udpsink host=10.253.5.151 port=5002
>
> and Sink
>
>       gst-launch-0.10  -v -e udpsrc port=5002
>              caps=application/x-rtp,media=audio,clock-rate=90000,
> encoding-name=MP4A-LATM,cpresent=0, \
>            
> config=NULL,payload=96,ssrc=3574762534,clock-base=2565233379,seqnum-base=29343
> \
>            ! gstrtpjitterbuffer \
>            ! rtpmp4adepay \
>            !
> audio/mpeg,channels=2,rate=44100,mpegversion=4,stream-format=raw,codec_data=\(buffer\)1210
>            ! ffdec_aac
>            ! pulsesink
>
> NOTE:  Actually sounds better without the jitter buffer.
>
> I tried modifying the source pipe to do ... ffenc-aac ! ffdec_aac !
> pulsesink.    Sound great.  I'm pretty sure that means the network or
> network elements are my problem.
>
> So, anyone have suggestions for getting better sound quality across the net?
> I know it's possible; other programs do it every day.
>
> ps.  I have also coded the receiver in C, with and without gstrtpbin.  Does
> not help.
>
> Warmly,
>
> Wers
>
>
>      

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wes Miller]

Here are the exact caps from fakesink as sent by the TI dm365 EVM board

/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = application/x-rtp, media=(string)audio, clock-rate=(int)90000, encoding-name=(string)MP4A-LATM, cpresent=(string)0, config=(string)NULL, payload=(int)96, ssrc=(guint)460723347, clock-base=(guint)2220768517, seqnum-base=(guint)59432

I did a cut-n-past (and changed ( to \(, etc.)  and still get Morse code, though now it sounds like lots of S's.

Wes

[Marco Ballesio]

Hi,

a few notes:

On Fri, Nov 19, 2010 at 5:08 PM, Wes Miller <[hidden email]> wrote:

>
> I have written simple pipes to encode an audiotestsrc sine wave into aac then
> mp4a payloadit and send it over the network to a matching udpsik, depay,
> decode and pulsesink.
>
> The sound comes out choppy, uniformly spaced, but chopped into beeps.
> Sounds a lot like Morse code but it's all E's.
>
> Here are the pipes: (they are on the same PC but I've also tried it between
> 2 computers)
>
> Source
>
>      gst-launch   audiotestsrc \
>           ! audio/x-raw-int, rate=44100, channels=2, endianness=1234,
> width=16, depth=16 \
>           ! ffenc_aac \
>           ! rtpmp4apay \
>           ! udpsink host=10.253.5.151 port=5002
>
> and Sink
>
>      gst-launch-0.10  -v -e udpsrc port=5002

I usually use gstrtpbin for this kind of pipelines. Btw I reas it did
not help in your case. Did you build the pipeline as reported in the
gstrtpbin examples?

>             caps=application/x-rtp,media=audio,clock-rate=90000,
> encoding-name=MP4A-LATM,cpresent=0, \
>
> config=NULL,payload=96,ssrc=3574762534,clock-base=2565233379,seqnum-base=29343

you don't need to explicitly set ssrc, clock-base and seqnum-base.
Very likely the same receiving pipeline does not work across two
separate sessions.

> \
>           ! gstrtpjitterbuffer \

dd you try to increase the latency value of the jitter buffer? You can
find a proper one by tcpdump-ing the traffic, measuring the maximim
jitter with e.g. wireshark and multiplying it by, let's say, a value
between 2 and 3.

>           ! rtpmp4adepay \
>           !
> audio/mpeg,channels=2,rate=44100,mpegversion=4,stream-format=raw,codec_data=\(buffer\)1210
>           ! ffdec_aac
>           ! pulsesink

As a trest, what if you set sync=false in pulsesink?

>
> NOTE:  Actually sounds better without the jitter buffer.

This is pretty strange, even though "better" is somewhat a subjective issue.

>
> I tried modifying the source pipe to do ... ffenc-aac ! ffdec_aac !
> pulsesink.    Sound great.  I'm pretty sure that means the network or
> network elements are my problem.

Probably yes, but it's unlikely in case you've a very good quality
network (e.g. ethernet over wire and very few clients active on it).
In any cases, you definitely need a jitter buffer.

Regards,
Marco

>
> So, anyone have suggestions for getting better sound quality across the net?
> I know it's possible; other programs do it every day.
>
> ps.  I have also coded the receiver in C, with and without gstrtpbin.  Does
> not help.
>
> Warmly,
>
> Wers
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/udpsink-to-udpsrc-choppy-stacato-sine-wave-tp3050472p3050472.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Marco Ballesio]

Hi,

another note. I should always re-read the emails before pushing "send" ;)

On Fri, Nov 19, 2010 at 5:08 PM, Wes Miller <[hidden email]> wrote:

..snip..

>
>      gst-launch-0.10  -v -e udpsrc port=5002
>             caps=application/x-rtp,media=audio,clock-rate=90000,

as Wim already pointed out, this is clearly wrong. As on the sending
pipeline the RTP clock will probably be set to 44100, setting it here
to 90000 is likely the cause of the morse code you're hearing.

Regards

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wes Miller]

Marco,

Tghanks for the notes.

First, I  got the 90000 by asking the sending pipe for its caps (fakesink).  I also tried 41400 and some ot her settings.  None improved the morse code though it effected the speed of it.

I did write this whole thing using gstrtpbin.  If you'll look at my other recent positing I was looking for help there and kind of had to wing it for a couple of answers.  Tehsound using the rtpbin is different but still choppy.  Sometimes more like wow and flutter than like Morse Code.

I did make a sort of wrap test where I sent data from one source into this pipe on the client.  Sounded great after I took most of the caps out between the payloader and depayloader.  NOTE:  One of my test programs latches onto one SSRC, so I did the depayload/payload so I could set fixed SSRCs.

     gst-launch -v udpsrc port=5012 caps=application/x-rtp ! rtpmp4adepay ! queue2 !  rtpmp4apay ssrc=30313233 ! udpsink host=10.253.5.151 port=5002
     
     
Wes

[Marco Ballesio]

Hi,

On Mon, Nov 22, 2010 at 2:44 PM, Wes Miller <[hidden email]> wrote:
>
> Marco,
>
> Tghanks for the notes.
>
> First, I  got the 90000 by asking the sending pipe for its caps (fakesink).
> I also tried 41400 and some ot her settings.

probably you meant 44100 and this is a typo. Fwiw, when I tested your
pipes I also got the morse got effect until I used the following:

gst-launch-0.10  udpsrc port=5002 !
"application/x-rtp,media=audio,clock-rate=44100,encoding-name=MP4A-LATM,cpresent=0,config=NULL,payload=96"
! gstrtpjitterbuffer ! rtpmp4adepay !
audio/mpeg,channels=2,rate=44100,mpegversion=4,stream-format=raw,codec_data=\(buffer\)1210
 ! ffdec_aac ! pulsesink

> None improved the morse code

Strange, not even when setting sync=false on pulsesink? There must
definitely be something wrong with your network/systems then. Maybe
you want to attach a tcpdump here.

> though it effected the speed of it.
>
> I did write this whole thing using gstrtpbin.  If you'll look at my other
> recent positing I was looking for help there and kind of had to wing it for
> a couple of answers.  Tehsound using the rtpbin is different but still
> choppy.  Sometimes more like wow and flutter than like Morse Code.
>
> I did make a sort of wrap test where I sent data from one source into this
> pipe on the client.  Sounded great after I took most of the caps out between
> the payloader and depayloader.  NOTE:  One of my test programs latches onto
> one SSRC, so I did the depayload/payload so I could set fixed SSRCs.

fixing the SSRC is not really the usual way to go, btw I don't know
what your requirements are. I understand that anyway things are now
working with the below mentioned pipeline (probably because negotiated
caps are just fine). You can dump what you negotiated using the -m -v
options in gst-launch.

Regards

>
>     gst-launch -v udpsrc port=5012 caps=application/x-rtp ! rtpmp4adepay !
> queue2 !  rtpmp4apay ssrc=30313233 ! udpsink host=10.253.5.151 port=5002
>
>
> Wes
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/udpsink-to-udpsrc-choppy-stacato-sine-wave-tp3050472p3053533.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wes Miller]

No, I really mena 90000.  FWIW this is a TI dm365 Evaluation board talking to an i686 PC.  It is possible that the folks at TI did something funny with the payload element.

Sorry, I hadn't tried the pulsesink -v when I last posted.  I'll see what happens in a bit and report here.  I spent a fortune in patience trying to get the gstrtpbin version working.  It's better but still sick.  I tried a version with one gstrtpbin and one with two, 0one for receive and one for send, in the same pipespec.  Again better, but not working.  I'll gather up my notes and paste a full biography and see if someone sees the light.

I've never done a tcpdump so that ought to be interesting.

Again, thanks for everything,

Wes

[Wes Miller]

Ok, first my apologies for being an idiot.  The stupid TI board does use 90000, but I tried this only on the PC.  It helps if you remember what you did.  So, to all, my apologies for the 90000 stuff.  I'll work on that next.

I tried the suggested pipeline with the caps taken out of the udpsrc and turned into a capsfilter.  Worked like a charm on the single PC.

Running the receiver pipe on the Ti dm365 EVM with TIAuddec1 replacing ffdec_aac, and changing pulsesink to alsasink sync=false, also works great.

Sending from the TI board is, however, not quite right yet.  Using the receiver pipe on the host PC I still get choppy output.  It really does seem to need a rate near 90000.  Hunting around gave me more or less better Morse code when rate is set between 60000 and 100000.  Changing pulse sync from false to true gives me either rapid stacato beeps or long slow been that are clearly sine waves, just chopped every so many milliseconds.

Well, more tomorrow.

Wes