From: Ron Y. <yor...@gm...> - 2009-09-29 23:48:49
|
Ok, I'm a little further now. I had an endianness issue that I was able to get around thanks to some other recent discussions on streaming audio in the last couple days. I'm now fighting some serious crackling I get when capturing from the mic and streaming the result across the network. On the capture side, I run this: gst-launch-0.10 -v alsasrc ! audio/x-raw-int,channels=1 ! audioconvert ! audio/x-raw-int,channels=1,depth=16,width=16,rate=24000,endianness=4321 ! rtpL16pay ! udpsink host=192.168.17.81 port=5435 And then the receiver: gst-launch-0.10 -v udpsrc port=5435 caps ="application/x-rtp, media=(string)audio, clock-rate=(int)32000, encoding-name=(string)L16, encoding-params=(string)1, channels=(int)1, channel-positions=(int)1, payload=(int)96, ssrc=(guint)1168011267, clock-base=(guint)309599748, seqnum-base=(guint)27324, endianness=1234" ! rtpL16depay ! audioconvert ! alsasink sync=false If I capture to a WAV file, and then stream that file across the network, I don't get any crackle. If I do the above capture across the network, I can barely make out the words I'm saying because of the crackle. Now, I'm using a 400Mhz Freescale iMX27 ARM CPU. When I do captures, I get warning messages like these: WARNING: from element /GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: Can't record audio fast enough Additional debug info: gstbaseaudiosrc.c(805): gst_base_audio_src_create (): /GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: dropped 480 samples I think I get more of these messages when I do a straight capture to the network, so it seems likely that the crackling has to do with the dropped samples. The lower the sample rate, the more messages I receive. I can't even capture at 8000 or 16000. I tried to fake my way around this issue by writing to a named pipe as follows: gst-launch-0.10 -v alsasrc ! audio/x-raw-int,channels=1 ! audioconvert ! audio/x-raw-int,channels=1,depth=16,width=16,rate=24000 ! audioconvert ! wavenc ! filesink location=/tmp/whee gst-launch -v --gst-debug=GST_CAT:3 filesrc location=/tmp/whee ! audio/x-raw-int,rate=24000,width=16,depth=16,channels=1,signed=true,endianness=1234 ! audioconvert ! rtpL16pay ! udpsink host=192.168.17.81 port=5435 But this has just as much crackling as sending straight across the network. Does anyone have suggestions on pipeline changes to get rid of the crackling? --Ron On Thu, Sep 24, 2009 at 8:26 AM, Ron Yorgason <yor...@gm...> wrote: > I have a Freescale iMX27. > > --Ron > > On Thu, Sep 24, 2009 at 6:54 AM, Andy Maginnis <ja...@sm...> wrote: >> Ron, >> What ARM are you using? We have a cortex A8, >> inside a OMAP3530 on a Gumstix Overo Water >> a >> >> -----Original Message----- >> From: Ron Yorgason [mailto:yor...@gm...] >> Sent: 23 September 2009 19:10 >> To: gst...@li... >> Subject: [gst-devel] sending raw audio >> >> I'm working on an audio/video streaming application on the ARM >> platform. We don't seem to have enough CPU horsepower on these boards >> to capture and encode to MP3, so right now we're trying to send raw >> audio. >> >> To capture & stream, I'm using this command: >> >> gst-launch-0.10 -v alsasrc ! >> audio/x-raw-int,rate=24000,width=16,depth=16,channels=1,signed=true ! >> audioconvert ! rtpL16pay ! udpsink host=192.168.17.81 port=5435 >> >> On the receiving side, I have this: >> gst-launch-0.10 -v udpsrc port=5435 caps ="application/x-rtp, >> media=(string)audio, clock-rate=(int)24000, encoding-name=(string)L16, >> encoding-params=(string)1, channels=(int)1, channel-positions=(int)1, >> payload=(int)96, ssrc=(guint)1168011267, clock-base=(guint)309599748, >> seqnum-base=(guint)27324" ! rtpL16depay ! audioconvert ! alsasink >> sync=false >> >> When I test this between my desktop & laptop, it works great. When I >> go from the ARM board to my desktop, it works ok. But when I go from >> the ARM board to another ARM board, or my laptop to the ARM board, I >> hear the speakers turn on, but no sound comes out. The output shows >> this: >> >> Setting pipeline to PAUSED ... >> Pipeline is live and does not need PREROLL ... >> Setting pipeline to PLAYING ... >> New clock: GstSystemClock >> /GstPipeline:pipeline0/GstRtpL16Depay:rtpl16depay0.GstPad:src: caps = >> audio/x-raw-int, endianness=(int)4321, signed=(boolean)true, >> width=(int)16, depth=(int)16, rate=(int)24000, channels=(int)1, >> channel-positions=(GstAudioChannelPosition)< >> GST_AUDIO_CHANNEL_POSITION_NONE > >> /GstPipeline:pipeline0/GstRtpL16Depay:rtpl16depay0.GstPad:sink: caps = >> application/x-rtp, media=(string)audio, clock-rate=(int)24000, >> encoding-name=(string)L16, encoding-params=(string)1, channels=(int)1, >> channel-positions=(int)1, payload=(int)96, ssrc=(guint)1168011267, >> clock-base=(guint)309599748, seqnum-base=(guint)27324 >> /GstPipeline:pipeline0/GstAudioConvert:audioconvert0.GstPad:src: caps >> = audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, >> width=(int)32, depth=(int)32, rate=(int)24000, channels=(int)1, >> channel-positions=(GstAudioChannelPosition)< >> GST_AUDIO_CHANNEL_POSITION_NONE > >> /GstPipeline:pipeline0/GstAudioConvert:audioconvert0.GstPad:sink: caps >> = audio/x-raw-int, endianness=(int)4321, signed=(boolean)true, >> width=(int)16, depth=(int)16, rate=(int)24000, channels=(int)1, >> channel-positions=(GstAudioChannelPosition)< >> GST_AUDIO_CHANNEL_POSITION_NONE > >> /GstPipeline:pipeline0/GstAlsaSink:alsasink0.GstPad:sink: caps = >> audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, >> width=(int)32, depth=(int)32, rate=(int)24000, channels=(int)1, >> channel-positions=(GstAudioChannelPosition)< >> GST_AUDIO_CHANNEL_POSITION_NONE > >> >> I couldn't find a good definition of what the >> GST_AUDIO_CHANNEL_POSITION_NONE means, and I wasn't able to set it to >> GST_AUDIO_CHANNEL_POSITION_MONO from the command line (it looks like I >> need to use python or C APIs to do that), but from what I can tell, >> this comes from multichannel support, and I have just specified a >> single audio channel. Is this what is preventing me from hearing the >> audio? If I capture to a WAV file, and then play it back afterwards, >> it sounds fine. So I'm not sure why streaming is failing so badly. >> The playback process also dies with a "Terminated" message within a >> minute or two. >> >> The ARM boards are running gstreamer-0.10.22. I see that there's been >> a couple revisions since then, and if I have to upgrade to make it >> work, I will. But I'd rather see if there's a way I can make this >> version work. >> >> --Ron >> >> ------------------------------------------------------------------------ >> ------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and >> stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> gstreamer-devel mailing list >> gst...@li... >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> gstreamer-devel mailing list >> gst...@li... >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel >> > |