Forum: GNU Radio First time user - fm radio tutorial has choppy audio

6ea19f5dbe0b4db05be8113f2aee8737?d=identicon&s=25 Chris Hallinan (Guest)
on 2015-01-14 18:45
(Received via mailing list)
Greetings, I'm a first time user of gnuradio.  Kudos to the developers,
it
only took me about a day to build gnuradio + gr-osmosdr (for my
el-cheapo
rtl2832 dongle) from source, including getting a basic FM broadcast
receiver sort-of running.  Host Ubuntu 14.04 on a very fast Dell
8-core server platform.

I've prototyped an FM receiver as described in the tutorial at the
bottom
of this page:
http://gnuradio.org/redmine/projects/gnuradio/wiki...

However, when I run it, and set the center frequency to a close-by FM
station, although I can hear actual broadcast audio snippets, meaning
that
it's actually receiving a coherent signal, it is very choppy, with audio
snippets being played in a very choppy, almost rhythmic fashion.  The
console window on gnuradio-companion shows a continuous series of
aUaUaU,
etc.

I'm guessing this might be an underrun situation somewhere, but that is
speculation.  I'm using parameters provided by the tutorial including a
sample rate 250K.  I've tried moving the sample rate around, but without
much improvement.  Dropping it down significantly destroys all hints of
intelligence in the signal ;)  Am I overtaxing the capabilities of this
rtl-sdr dongle?

I have a reasonable (and growing) understand of the core concepts, but
could use some help on the learning curve.

Any advice appreciated.

-Chris
D17685d174fee4ca258c75cce7bc2202?d=identicon&s=25 Marcus Müller (Guest)
on 2015-01-14 18:54
(Received via mailing list)
Hi Chris,
On 01/14/2015 06:44 PM, Chris Hallinan wrote:
> Greetings, I'm a first time user of gnuradio.
Welcome!
>
> I'm guessing this might be an underrun situation somewhere, but that
> is speculation.
But speculation that's probably correct :)
aU is audio underrun, which means you're most probably supplying samples
at a rate that's lower than the audio sink is configured to accept.
> I'm using parameters provided by the tutorial including a sample rate
> 250K.  I've tried moving the sample rate around, but without much
> improvement.  Dropping it down significantly destroys all hints of
> intelligence in the signal ;)  Am I overtaxing the capabilities of
> this rtl-sdr dongle?
Probably not, since you're doing so well this far! Basically, use a
sampling rate that works, and decimate to exactly the sampling rate you
need for your audio sink.

>
> I have a reasonable (and growing) understand of the core concepts, but
> could use some help on the learning curve.
>
> Any advice appreciated.
>
see above :)

Greetings, and happy hacking,
Marcus
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2015-01-14 18:55
(Received via mailing list)
On 01/14/2015 12:44 PM, Chris Hallinan wrote:
> However, when I run it, and set the center frequency to a close-by FM
> destroys all hints of intelligence in the signal ;)  Am I overtaxing
>
> --
> Life is like Linux - it never stands still.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
You almost certainly have a sample-rate mismatch somewhere in the
flow--likely, your audio sink is configured for a sample-rate other than
what
   the hardware (or PulseAudio) can support.  Sometimes also, PulseAudio
gets into trouble and gets all under-runny.   I'd go with Alsa direct if
it
   were my problem, and skip Pulse entirely.
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2015-01-14 19:09
(Received via mailing list)
On Wed, Jan 14, 2015 at 12:53 PM, Marcus D. Leech <mleech@ripnet.com>
wrote:

>
> speculation.  I'm using parameters provided by the tutorial including a
>  -Chris
>  You almost certainly have a sample-rate mismatch somewhere in the
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
The manual gives you a few hints for different possible device names you
can try:

http://gnuradio.org/doc/doxygen/classgr_1_1audio_1...

Unlike Marcus, I've always had better luck with pulse that direct alsa.
But
we have very different systems and use different Linux versions, so
ymmv.

Tom
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2015-01-15 05:29
(Received via mailing list)
Hi,

How would I change this, skipping PulseAudio and using Alsa? The only
audio application I try with gnuradio at the moment behaves similar
here. I try to decode DMR, and I get choppy audio although everything
should be OK. I blamed gr-dsd, but maybe it is a common issue. Will have
to try a simple FM RX to verify :)

Ralph.
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2015-01-15 05:33
(Received via mailing list)
On 01/14/2015 11:28 PM, Ralph A. Schmid, dk5ras wrote:
> Hi,
>
> How would I change this, skipping PulseAudio and using Alsa? The only audio
application I try with gnuradio at the moment behaves similar here. I try to
decode DMR, and I get choppy audio although everything should be OK. I blamed
gr-dsd, but maybe it is a common issue. Will have to try a simple FM RX to 
verify
:)
>
> Ralph.
>
>> You almost certainly have a sample-rate mismatch somewhere in the flow--likely,
your audio sink is configured for a sample-rate other than what
>> the hardware (or PulseAudio) can support.  Sometimes also, PulseAudio gets into
trouble and gets all under-runny.   I'd go with Alsa direct if it
>> were my problem, and skip Pulse entirely.
>
One could just try dial_tone.py example.  That will exercise the audio
subsystem.

For alsa, in the device field in the audio sink, try something like
hw:0,0  or plughw:0,0
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2015-01-15 06:30
(Received via mailing list)
>One could just try dial_tone.py example.  That will exercise the audio subsystem.

Output is some garbled noise, and

python$ python dial_tone.py
INFO: Audio sink arch: alsa
aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU

So my audio stuff is defective, good to know :)

>For alsa, in the device field in the audio sink, try something like
>hw:0,0  or plughw:0,0

Seems to be alsa already...hmm...so this comes later.

Ralph.
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2015-01-15 06:41
(Received via mailing list)
On 01/15/2015 12:29 AM, Ralph A. Schmid, dk5ras wrote:
>> hw:0,0  or plughw:0,0
> Seems to be alsa already...hmm...so this comes later.
>
> Ralph.
>
>
It may just be that your audio-subsystem doesn't actually support the
sample-rate that the graph is configuring it for.

Here's the --help for dial_tone.py

Usage: dial_tone.py [options]

Options:
   -h, --help            show this help message and exit
   -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT
                         pcm output device name.  E.g., hw:0,0 or
/dev/dsp
   -r SAMPLE_RATE, --sample-rate=SAMPLE_RATE
                         set sample rate to RATE (48000)



Looks like the default is 48e3

Try other rates, like 44.1e3  or 32e3
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2015-01-15 06:50
(Received via mailing list)
>It may just be that your audio-subsystem doesn't actually support the sample-rate
that the graph is configuring it for.

Maybe. At least the test audio from the audio control panel is clear.

>Here's the --help for dial_tone.py

>Usage: dial_tone.py [options]

>Options:
 >  -h, --help            show this help message and exit
 > -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT
 >                       pcm output device name.  E.g., hw:0,0 or
/dev/dsp
 >  -r SAMPLE_RATE, --sample-rate=SAMPLE_RATE
 >                        set sample rate to RATE (48000)



>Looks like the default is 48e3

>Try other rates, like 44.1e3  or 32e3

I will test it and tell you :)

Ralph.
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2015-01-15 07:17
(Received via mailing list)
Only 44100 works, giving a clear dial tone. As DSD has fixed sampling
rate 8k, a resampler should do the trick. Things could be so easy :) I
hate this audio stuff...

Ralph.
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2015-01-15 07:22
(Received via mailing list)
On 01/15/2015 01:15 AM, Ralph A. Schmid, dk5ras wrote:
> Only 44100 works, giving a clear dial tone. As DSD has fixed sampling rate 8k, a
resampler should do the trick. Things could be so easy :) I hate this audio
stuff...
>
> Ralph.
If you use "plughw:0,0" as the hardware designator, it's often willing
to do resampling to the actual hardware rate.
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2015-01-15 08:15
(Received via mailing list)
Hi Marcus,

> If you use "plughw:0,0" as the hardware designator, it's often willing to do
> resampling to the actual hardware rate.

Yep, I will try this later. Made my tests this morning on my way to work
by train, now it has to wait until lunch break :)

Ralph.
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2015-01-15 13:48
(Received via mailing list)
No chance, I do not get any stable audio performance, I assume the
Kubuntu
sound system is defective somehow. It is not about sampling rates, the
pitch
is correct, just choppy. When calling the dial tone script repeatedly,
sometimes it works, sometimes it causes garbled sounds, then again it
works,
with one attempt after another without doing anything else.

Update: Right now I was so brave to uninstall some pulse library stuff,
and
what should I say, the stuttering is gone, DMR is not decoding 100%
fine,
but I assume now it is a matter of fine tuning the receiver chain and
decoder, audio itself looks OK. Thank you very much for putting me into
the
right direction! How can find such a load of BS its way into an official
and
widely used Linux distribution?!

Ralph.


> -----Original Message-----
> From: discuss-gnuradio-bounces+ralph=schmid.xxx@gnu.org
> [mailto:discuss-gnuradio-bounces+ralph=schmid.xxx@gnu.org] On Behalf Of
> Ralph A. Schmid, dk5ras
> Sent: Thursday, January 15, 2015 8:14 AM
> To: 'Marcus D. Leech'; 'Tom Rondeau'
> Cc: 'GNURadio Discussion List'
> Subject: Re: [Discuss-gnuradio] First time user - fm radio tutorial has
choppy
> audio
>
> Hi Marcus,
>
> > If you use "plughw:0,0" as the hardware designator, it's often willing
> > to do resampling to the actual hardware rate.
>
> Yep, I will try this later. Made my tests this morning on my way to work
by
9ddaba70c434f77294db7bb4d5119c31?d=identicon&s=25 Remington Furman (Guest)
on 2015-01-15 22:39
(Received via mailing list)
Hi,

I had this same aU problem a few months ago on Linux Mint, but was able
to
resolve it by editing the default ALSA settings in
~/.gnuradio/config.conf .

I will send detailed notes on the exact fix I made when I get home, but
I
just found this page also describing the fix:
http://www.funwithelectronics.com/?id=167
(Increase 'nperiods' under [audio_alsa])

After the config change ALSA audio worked with my own WBFM flowgraph and
all the sample flowgraphs that were previously broken for me.

Apologies for not sending something to the list when I found the
problem.
I knew it would have saved folks from some hair pulling.

Hope this helps,
-Remington
W7REM

On Thu, Jan 15, 2015 at 4:47 AM, Ralph A. Schmid, dk5ras
<ralph@schmid.xxx>
9ddaba70c434f77294db7bb4d5119c31?d=identicon&s=25 Remington Furman (Guest)
on 2015-01-16 05:43
(Received via mailing list)
Ok, here are the contents of my ~/.gnuradio/config.conf:

[audio_alsa]
default_input_device = default
default_output_device = default
#period_time = 0.010                      # in seconds (default)
period_time = 0.100                      # in seconds
nperiods = 4                 # total buffering = period_time * nperiods
#verbose = false
verbose = true

The actual change I made was to increase audio_alsa/period_time from
0.010
to 0.100.  Play around with it until it works on your system.  My only
guess is that perhaps the default ALSA buffer sizes are small enough
that
they are often consumed by ALSA before GnuRadio will fill them.

Cheers,
-Remington

PS. Thanks to everyone for your fantastic work on building this whole
system and answering all the questions on the list.  I've been learning
a
ton reading this over the last year, and I appreciate it.  I'll try not
to
be so shy next time I know something that might be useful to others.

On Thu, Jan 15, 2015 at 1:38 PM, Remington Furman <remicles2@gmail.com>
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2015-01-16 11:38
(Received via mailing list)
Good to know! In my case it was a pulse issue, and removing parts of
this stuff fixed it, but who know what else may happen :)



At least now gr-dsd works, I can decode DMR transmissions with it in
relative good quality, and also other audio applications should cause no
trouble. Not that I do very much audio stuff, for receiving audio
usually I use Windows / HDSDR.



And I only can second your “thanks guys” message. Great work, gnuradio
is a fantastic tool that opens whole new worlds!



Ralph.



From: Remington Furman [mailto:remicles2@gmail.com]
Sent: Friday, January 16, 2015 5:42 AM
To: Ralph A. Schmid, dk5ras
Cc: Marcus D. Leech; Tom Rondeau; Christopher Hallinan; GNURadio
Discussion List
Subject: Re: [Discuss-gnuradio] First time user - fm radio tutorial has
choppy audio



Ok, here are the contents of my ~/.gnuradio/config.conf:

[audio_alsa]
default_input_device = default
default_output_device = default
#period_time = 0.010                      # in seconds (default)
period_time = 0.100                      # in seconds
nperiods = 4                 # total buffering = period_time * nperiods
#verbose = false

verbose = true


The actual change I made was to increase audio_alsa/period_time from
0.010 to 0.100.  Play around with it until it works on your system.  My
only guess is that perhaps the default ALSA buffer sizes are small
enough that they are often consumed by ALSA before GnuRadio will fill
them.

Cheers,

-Remington

PS. Thanks to everyone for your fantastic work on building this whole
system and answering all the questions on the list.  I've been learning
a ton reading this over the last year, and I appreciate it.  I'll try
not to be so shy next time I know something that might be useful to
others.



On Thu, Jan 15, 2015 at 1:38 PM, Remington Furman <remicles2@gmail.com
<mailto:remicles2@gmail.com> > wrote:

Hi,



I had this same aU problem a few months ago on Linux Mint, but was able
to resolve it by editing the default ALSA settings in
~/.gnuradio/config.conf .



I will send detailed notes on the exact fix I made when I get home, but
I just found this page also describing the fix:

http://www.funwithelectronics.com/?id=167

(Increase 'nperiods' under [audio_alsa])



After the config change ALSA audio worked with my own WBFM flowgraph and
all the sample flowgraphs that were previously broken for me.



Apologies for not sending something to the list when I found the
problem.  I knew it would have saved folks from some hair pulling.



Hope this helps,

-Remington

W7REM



On Thu, Jan 15, 2015 at 4:47 AM, Ralph A. Schmid, dk5ras
<ralph@schmid.xxx <mailto:ralph@schmid.xxx> > wrote:

No chance, I do not get any stable audio performance, I assume the
Kubuntu
sound system is defective somehow. It is not about sampling rates, the
pitch
is correct, just choppy. When calling the dial tone script repeatedly,
sometimes it works, sometimes it causes garbled sounds, then again it
works,
with one attempt after another without doing anything else.

Update: Right now I was so brave to uninstall some pulse library stuff,
and
what should I say, the stuttering is gone, DMR is not decoding 100%
fine,
but I assume now it is a matter of fine tuning the receiver chain and
decoder, audio itself looks OK. Thank you very much for putting me into
the
right direction! How can find such a load of BS its way into an official
and
widely used Linux distribution?!

Ralph.


> -----Original Message-----
> From: discuss-gnuradio-bounces+ralph=schmid.xxx@gnu.org
<mailto:schmid.xxx@gnu.org>
> [mailto:discuss-gnuradio-bounces+ralph <mailto:discuss-gnuradio-bounces%2Bralph>
=schmid.xxx@gnu.org <mailto:schmid.xxx@gnu.org> ] On Behalf Of
> Ralph A. Schmid, dk5ras
> Sent: Thursday, January 15, 2015 8:14 AM
> To: 'Marcus D. Leech'; 'Tom Rondeau'
> Cc: 'GNURadio Discussion List'
> Subject: Re: [Discuss-gnuradio] First time user - fm radio tutorial has
choppy
> audio
>

> Hi Marcus,
>
> > If you use "plughw:0,0" as the hardware designator, it's often willing
> > to do resampling to the actual hardware rate.
>
> Yep, I will try this later. Made my tests this morning on my way to work
by
6ea19f5dbe0b4db05be8113f2aee8737?d=identicon&s=25 Chris Hallinan (Guest)
on 2015-01-16 20:25
(Received via mailing list)
On Thu, Jan 15, 2015 at 11:42 PM, Remington Furman <remicles2@gmail.com>
wrote:

>
> The actual change I made was to increase audio_alsa/period_time from 0.010
> to 0.100.  Play around with it until it works on your system.  My only
> guess is that perhaps the default ALSA buffer sizes are small enough that
> they are often consumed by ALSA before GnuRadio will fill them.
>

Ah ha!
Thanks, Remington.  That was my issue.  My first clue should have been
that
I was hearing intelligible signal, even though very choppy.  That alone
suggest that my flow graph was properly configured with respect to
sampling
rates, rate conversion (resampling), etc.  Your settings did not work
directly on my system (almost stock Ubuntu 14.04) , but improved my
situation significantly.  After trying your settings, I got proper sound
for about .5 seconds, followed by perhaps a quarter second of dropout.
Playing around, I got smooth audio using these settings:

period_time = 0.400
nperiods = 16

I guess I'm gonna have to learn more about ALSA than I ever wanted to!

Thanks much!

-Chris
F1f86e42d3455453160d7402256dfb32?d=identicon&s=25 Shahnaz Sh (shahnaz)
on 2016-05-11 06:46
Chris Hallinan wrote in post #1166653:
> Greetings, I'm a first time user of gnuradio.  Kudos to the developers,
> it
> only took me about a day to build gnuradio + gr-osmosdr (for my
> el-cheapo
> rtl2832 dongle) from source, including getting a basic FM broadcast
> receiver sort-of running.  Host Ubuntu 14.04 on a very fast Dell
> 8-core server platform.
>
> I've prototyped an FM receiver as described in the tutorial at the
> bottom
> of this page:
>
http://gnuradio.org/redmine/projects/gnuradio/wiki...
>
> However, when I run it, and set the center frequency to a close-by FM
> station, although I can hear actual broadcast audio snippets, meaning
> that
> it's actually receiving a coherent signal, it is very choppy, with audio
> snippets being played in a very choppy, almost rhythmic fashion.  The
> console window on gnuradio-companion shows a continuous series of
> aUaUaU,
> etc.
>
> I'm guessing this might be an underrun situation somewhere, but that is
> speculation.  I'm using parameters provided by the tutorial including a
> sample rate 250K.  I've tried moving the sample rate around, but without
> much improvement.  Dropping it down significantly destroys all hints of
> intelligence in the signal ;)  Am I overtaxing the capabilities of this
> rtl-sdr dongle?
>
> I have a reasonable (and growing) understand of the core concepts, but
> could use some help on the learning curve.
>
> Any advice appreciated.
>
> -Chris

Hi Chris,

Sorry to ask out of contents question but may I ask which way you chose
to install the Gnu Radio from source?
did you use Pybombs?

regards,
Shahnaz
This topic is locked and can not be replied to.