[gst-devel] sending raw audio
Ron Yorgason
yorgasor at gmail.com
Wed Sep 30 01:48:35 CEST 2009
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 <yorgasor at gmail.com> wrote:
> I have a Freescale iMX27.
>
> --Ron
>
> On Thu, Sep 24, 2009 at 6:54 AM, Andy Maginnis <jam at smru.co.uk> 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:yorgasor at gmail.com]
>> Sent: 23 September 2009 19:10
>> To: gstreamer-devel at lists.sourceforge.net
>> 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
>> gstreamer-devel at lists.sourceforge.net
>> 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
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>
More information about the gstreamer-devel
mailing list