gqrx Kubuntu14.04: Crackling sound after hours

[wofritzyt]

Hi,

I have a weird problem with gqrx on Linux 14.04. It may not be gqrx specific, but a general problem:

After running for long time, some crackling appears in the audio. First I thought it was received static, but it is absolutely reproducible. Just wait long enough.

When this happens, I get the line

Flushing pa_sink

in the terminal. I have not checked the code in detail, but it seems the audio buffers are slowly filled up and then have to be flushed to make room again.

I suspect that the samples are output slightly slower than they are generated. Output rate is determined by the sound card hardware. How is the input rate determined? Is it derived from the sample rate of the SDR device? In this case, there is always some difference in the samples rates since both devices have their own clock generators.

Anyone seen this?

Wolf, DK7OB
 

[Adrian Musceac]

Hi Wolf,
Using a standard gnuradio audio sink, this should not matter. Pulseaudio has its quirks, although it is miles more user friendly than Alsa.
If your waveform requirements are critical, go through Alsa first and let it handle the float stream.
hope this helps,

Adrian

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Alexandru Csete]

On Fri, Apr 1, 2016 at 9:05 AM, wofritzyt <wolfgan...@gmx.net> wrote:
> Hi,
>
> I have a weird problem with gqrx on Linux 14.04. It may not be gqrx
> specific, but a general problem:
>
> After running for long time, some crackling appears in the audio. First I
> thought it was received static, but it is absolutely reproducible. Just wait
> long enough.
>
> When this happens, I get the line
>
> Flushing pa_sink
>
> in the terminal. I have not checked the code in detail, but it seems the
> audio buffers are slowly filled up and then have to be flushed to make room
> again.

The flushing occurs at regular intervals (some minutes), so you should
see those message also in the beginning. It is just a primitive
attempt at avoiding latency build up in case the sound card rate is
slower than it should be.

> I suspect that the samples are output slightly slower than they are
> generated. Output rate is determined by the sound card hardware. How is the
> input rate determined? Is it derived from the sample rate of the SDR device?
> In this case, there is always some difference in the samples rates since
> both devices have their own clock generators.

I don't understand what you mean by "determining the input rate".
Clearly, the input rate is determined by the SDR hardware, just like
the output rate is determined by the sound card. The sample rate
mismatch will always exist unless some adaptive resampling is
implemented.

Alex

[Wolfgang Fritz]

Am 03.04.2016 um 01:11 schrieb Alexandru Csete:
> On Fri, Apr 1, 2016 at 9:05 AM, wofritzyt <wolfgan...@gmx.net> wrote:
>> Hi,
>>
>> I have a weird problem with gqrx on Linux 14.04. It may not be gqrx
>> specific, but a general problem:
>>
>> After running for long time, some crackling appears in the audio. First I
>> thought it was received static, but it is absolutely reproducible. Just wait
>> long enough.
>>
>> When this happens, I get the line
>>
>> Flushing pa_sink
>>
>> in the terminal. I have not checked the code in detail, but it seems the
>> audio buffers are slowly filled up and then have to be flushed to make room
>> again.
>
> The flushing occurs at regular intervals (some minutes), so you should
> see those message also in the beginning. It is just a primitive
> attempt at avoiding latency build up in case the sound card rate is
> slower than it should be.
>

Yes, I've seen that now, from the code it should be 300 seconds, if I'm
not wrong. So it's probably not the reason for the crackling sound,
because that really happens only after hours.

>
>> I suspect that the samples are output slightly slower than they are
>> generated. Output rate is determined by the sound card hardware. How is the
>> input rate determined? Is it derived from the sample rate of the SDR device?
>> In this case, there is always some difference in the samples rates since
>> both devices have their own clock generators.
>
> I don't understand what you mean by "determining the input rate".
> Clearly, the input rate is determined by the SDR hardware, just like
> the output rate is determined by the sound card. The sample rate
> mismatch will always exist unless some adaptive resampling is
> implemented.
>

It's probably a combination of my less than perfect English and
the missing knowledge in digital signal processing. But you got it right
anyway ;-)

I come into similar clocking problems at work regularly. Usually we have
all device clocks generated from the same master clock, so at least
there is no problem on board level. But on some types of transmission
paths the clock info gets lost.

The most simple approach is to supervise the buffer fill levels, and if
they reach certain limit, single samples are either left out or
duplicated. This works for PCM speech signals quite well, you usually
don not hear it.

> Alex
>

[wofritzyt]

I built gqrx with gr-audio support.
The "Flushing pa_sink" messages are gone, so I think it's really using gr-audio.
No crackling sound for now.
Audio latency seems to be lower too compared to my transceiver.
I get "aU" printed on the terminal sometimes, have to check what that means.
And there is only the "Default" device in the audio selection.

[Adrian Musceac]

Hi,
gnuradio is using Alsa by default.
aU messages signify "audio underrun".
I would not worry about them unless you get a lot of such messages.
cheers,
Adrian