sound problem

299 views
Skip to first unread message

s51da

unread,
May 5, 2015, 2:25:16 AM5/5/15
to gq...@googlegroups.com
Hi,

I'm new to the group, but I use Gqrx for quite some time. I have a problem with fluttering sound.

Working conditions are:

-i7-4770, 8gb ram, SSD
-Fedora 21 Kernel 3.19.5-200 x86_64
-Pulseaudio 6.0
-Gnuradio 3.7.7 built from source
-Gqrx v2.3.2-97-g706b

When I use RTL_SDR dongle at high sample rate like 2.8M sound starts to flutter, break, crackle... and it gets worse with time.

Output form pulseaudio -vvvvv:

D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (464 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (464 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (464 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (464 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (464 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (464 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (400 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (400 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (400 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (400 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (400 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 16 bytes ago (400 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] protocol-native.c: Implicit underrun of 'Audio output'
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 40 bytes ago (376 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 40 bytes ago (376 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 40 bytes ago (376 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 40 bytes ago (344 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 168 bytes ago (312 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 168 bytes ago (312 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] sink.c: Found underrun 168 bytes ago (312 bytes ahead in playback buffer)
D: [alsa-sink-ALC887-VD Analog] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink-ALC887-VD Analog] alsa-sink.c: Requested to rewind 168 bytes.
D: [alsa-sink-ALC887-VD Analog] alsa-sink.c: Limited to 168 bytes.
D: [alsa-sink-ALC887-VD Analog] alsa-sink.c: before: 42
D: [alsa-sink-ALC887-VD Analog] alsa-sink.c: after: 42
D: [alsa-sink-ALC887-VD Analog] alsa-sink.c: Rewound 168 bytes.
D: [alsa-sink-ALC887-VD Analog] sink.c: Processing rewind...
D: [alsa-sink-ALC887-VD Analog] sink.c: latency = 1410
D: [alsa-sink-ALC887-VD Analog] sink-input.c: Have to rewind 168 bytes on render memblockq.
D: [alsa-sink-ALC887-VD Analog] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink-ALC887-VD Analog] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink-ALC887-VD Analog] source.c: Processing rewind...
D: [alsa-sink-ALC887-VD Analog] protocol-native.c: Implicit underrun of 'Audio output'

If the sample rate is lower underruns are fewer and the sound is better, but not much.

If I use fcd dongle v1.1, pulseaudio output is:

D: [alsa-sink-ALC887-VD Analog] ratelimit.c: 3865 events suppressed
D: [alsa-sink-ALC887-VD Analog] memblock.c: Pool full
D: [alsa-sink-ALC887-VD Analog] memblock.c: Pool full
D: [alsa-sink-ALC887-VD Analog] memblock.c: Pool full
D: [pulseaudio] memblock.c: Pool full
D: [alsa-sink-ALC887-VD Analog] memblock.c: Pool full
D: [alsa-sink-ALC887-VD Analog] memblock.c: Pool full
D: [pulseaudio] memblock.c: Pool full
D: [alsa-sink-ALC887-VD Analog] memblock.c: Pool full
D: [alsa-sink-ALC887-VD Analog] memblock.c: Pool full
D: [alsa-sink-ALC887-VD Analog] memblock.c: Pool full
D: [pulseaudio] memblock.c: Pool full
D: [alsa-sink-ALC887-VD Analog] ratelimit.c: 4169 events suppressed

there is no underruns, and the sound is good.

The problem exists from quite some time. It was also present on older setup, on Fedora 20, older kernels, older versions of Gqrx.
I've tried a lot of things like: pulse_latency_msec=30, tshed=0 for timing and also compiling Gqrx without pulse audio support.
Without pulseaudio support the sound is terrible, unusable, totally chopped.

While running, processor is not struggling. All 8 threads are on less than 1% when the sound is OK on start, but after some time when the problem appears, they go up to around 10%.

Any ideas what to do?

73
David

Alexandru Csete

unread,
May 5, 2015, 9:51:45 AM5/5/15
to gq...@googlegroups.com
On Tue, May 5, 2015 at 8:25 AM, s51da <david...@gmail.com> wrote:
> Hi,
>
> I'm new to the group, but I use Gqrx for quite some time. I have a problem
> with fluttering sound.
>
> Working conditions are:
>
> -i7-4770, 8gb ram, SSD
> -Fedora 21 Kernel 3.19.5-200 x86_64
> -Pulseaudio 6.0
> -Gnuradio 3.7.7 built from source
> -Gqrx v2.3.2-97-g706b
>
> When I use RTL_SDR dongle at high sample rate like 2.8M sound starts to
> flutter, break, crackle... and it gets worse with time.

From the rtlsdr website (http://sdr.osmocom.org/trac/wiki/rtl-sdr):

"The RTL2832U outputs 8-bit I/Q-samples, and the highest theoretically
possible sample-rate is 3.2 MS/s, however, the highest sample-rate
without lost samples that has been tested so far is 2.56 MS/s."

So, when gqrx is configured to use 2.8 Msps input but some of those
are lost, you get the behaviour that you observe.


> If the sample rate is lower underruns are fewer and the sound is better, but
> not much.

There could still be a mismatch between the requested sample sample
rate and the actual rate samples are delivered. You can try different
sample rates or different devices. Also, a different USB port could
make a difference. Keep in mind, this is cheap hardware with a reverse
engineered driver.

Alex

s51da

unread,
May 6, 2015, 6:03:03 AM5/6/15
to gq...@googlegroups.com
I'll try what you suggested. I have a few different receivers.

David
Reply all
Reply to author
Forward
0 new messages