First time user - fm radio tutorial has choppy audio

[addis_a]

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/Guided_Tutorial_Hardware_Considerations

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

[Chris_H.inan]

On 01/14/2015 12:44 PM, Chris H.inan 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
[email protected]
Discuss-gnuradio Info Page
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.

[Chris_H.inan]

Hi Chris,
On 01/14/2015 06:44 PM, Chris H.inan 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

[Chris_H.inan]

On Wed, Jan 14, 2015 at 12:53 PM, Marcus D. Leech [email protected]
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_1sink.html

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

[Chris_H.inan]

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.

[Chris_H.inan]

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

[Chris_H.inan]

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.

[Chris_H.inan]

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

[Chris_H.inan]

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.

[Chris_H.inan]

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.

[Chris_H.inan]

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.

[Chris_H.inan]

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.

[Chris_H.inan]

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=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+ralph=removed_email_address@domain.invalid] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Thursday, January 15, 2015 8:14 AM
To: ‘Marcus D. Leech’; ‘Tom R.’
Cc: ‘GNURadio D.ion 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

[Chris_H.inan]

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
[email protected]

[Chris_H.inan]

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 F. [email protected]

[Chris_H.inan]

On Thu, Jan 15, 2015 at 11:42 PM, Remington F. [email protected]
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

[Chris_H.inan]

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 F. [mailto:[email protected]]
Sent: Friday, January 16, 2015 5:42 AM
To: Ralph A. Schmid, dk5ras
Cc: Marcus D. Leech; Tom R.; Christopher Hallinan; GNURadio
Discussion L.
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 F. <[email protected]
mailto:[email protected] > 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
<[email protected] mailto:[email protected] > 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=removed_email_address@domain.invalid
mailto:[email protected]
[mailto:discuss-gnuradio-bounces+ralph mailto:discuss-gnuradio-bounces%2Bralph
[email protected] mailto:[email protected] ] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Thursday, January 15, 2015 8:14 AM
To: ‘Marcus D. Leech’; ‘Tom R.’
Cc: ‘GNURadio D.ion 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

[Chris_H.inan]

Chris H.inan 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/Guided_Tutorial_Hardware_Considerations

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

[rolf]

I had the same problem and disabling PulseAudio in combination with the previously mentioned change in ALSA config worked for me:
https://kodi.wiki/view/PulseAudio/HOW-TO:_ Disable_PulseAudio_and_use_ALSA_(without_removing_PulseAudio)_for_Ubuntu

Works fine now.

Im having issues with adding the link. Just copy paste the whole thing.

-Rolf

[voyalgru]

can someone give me a step by step tutorial on how to do this… I’m new to linux, and new to gnu…

everywhere I look everyone just says its easy you just have to edit the ~/.gnuradio/config.conf

I don’t have enough information too even know what to look for.

How and what files do I copy and from where to edit or create the “fix”???

please make it simple ex…

• hit “alt+t” or “ctrl+alt+t” to open a command line window.
• type sudo (insert junk here)
• then you’ll want to (more junk with juicy details)
• now you can type…

[audio_alsa]
nperiods = 16
period_time = 0.100

… I would appreciate it, thank you