Audio stuttering/crackling fixed, I hope

[Alexandru Csete]

Greetings,

There have been many reports over the years about stuttering /
crackling / choppy audio while using the pulseaudio backend. Although
this happens in pulseaudio and/or the linux audio system, I have made
some changes in gqrx which I believe avoids this problem.

I have tested all day and I can no longer trigger the crackling audio
problem. The changes are now comitted, so please try it out if you
have been suffering from this issue and you can build the code from
the repository.

Alex

[wofritzyt]

Hi Alex,

I'll try this immediately. I am suffering from crackling sound with my USB sound stick and tried to fix this during my holiday, with only limited success. I even rewrote the pa_sink to use the asynchronous multithreaded pulseaudio API. At least my experiments showed that the crackling were caused by pulse audio underruns. My current code checks for underruns and if there are too many, it increases the pulse audio buffer sizes. This helps but with my bad USB stick it takes some time to adjust (this stick needs 80ms latency to work without underruns).

One "issue" I observe is that the audio data is processed quite "bursty", meaning the FIFO level in my pa_sink implementation sometimes goes very high and sometimes drops to zero, causing an underrun. I don't know the reason for this. Is it gqrx core delivering data too bursty or is i pulse audio requesting data too bursty or is it a non optimal interaction between the gqrx write thread and the pulse audio read thread.

BTW, because I have no crackling audio with cubicsdr. I checked the code and the pulse audio sink is basically the same as in gqrx, using pulse audio "simple" API.. But it goes the "safe" way and configures pulse audio buffers for 100ms latency. This is good enough even for my USB stick, but adds quite some latency, so total latency with cubicsdr is 400ms from RF in to AF out which is much more than gqrx.

Regards,
Wolf, DK7OB

[Alexandru Csete]

On Sun, Aug 14, 2016 at 10:34 AM, wofritzyt <wolfgan...@gmx.net> wrote:
> Hi Alex,
>
> I'll try this immediately. I am suffering from crackling sound with my USB
> sound stick and tried to fix this during my holiday, with only limited
> success. I even rewrote the pa_sink to use the asynchronous multithreaded
> pulseaudio API. At least my experiments showed that the crackling were
> caused by pulse audio underruns. My current code checks for underruns and if
> there are too many, it increases the pulse audio buffer sizes. This helps
> but with my bad USB stick it takes some time to adjust (this stick needs
> 80ms latency to work without underruns).

All I have done to "fix" the issue is to remove the code that set a
low latency and use the default pulseaudio latency.

I can imagine there may still be issues if the hardware does not
support 48 kHz and pulseaudio has to resample. On the other hand, I
looked in my pulseaudio configuration files and it seems the global
sample rate is 44.1 kHz, so pulseaudio may in any case be doing a lot
of resampling.

By the way, the resampler type and quality can also be configured for
pulseaudio.

As far as I remember, we have everything in place to support audio
rates other than 48 kHz. It's just the GUI part that need finishing.
So that's also an option.

> One "issue" I observe is that the audio data is processed quite "bursty",
> meaning the FIFO level in my pa_sink implementation sometimes goes very high
> and sometimes drops to zero, causing an underrun. I don't know the reason
> for this. Is it gqrx core delivering data too bursty or is i pulse audio
> requesting data too bursty or is it a non optimal interaction between the
> gqrx write thread and the pulse audio read thread.

It's the GNU Radio scheduler that determines that, although I think it
is pretty much driven by how samples are delivered from the input
source.

>
> BTW, because I have no crackling audio with cubicsdr. I checked the code and
> the pulse audio sink is basically the same as in gqrx, using pulse audio
> "simple" API.. But it goes the "safe" way and configures pulse audio buffers
> for 100ms latency. This is good enough even for my USB stick, but adds quite
> some latency, so total latency with cubicsdr is 400ms from RF in to AF out
> which is much more than gqrx.

If it helps, we can add the latency parameter as a configuration
option. It is also available in the simple API.

While looking into audio issues on the Raspberry Pi, I saw someone
recommending to comment out the following line in
/etc/pulse/default.pa:
load-module module-suspend-on-idle

That had also something to do with crackling, in that the device was
constantly switched on and off.

By the way, I just tried to see the RF-to-audio latency on my
computer, using a Funcube Dongle Pro+. It didn't feel like more than
50 msec between keying and audio, maybe even less.

Alex

[Wolfgang Fritz]

Am 14.08.2016 um 12:05 schrieb Alexandru Csete:
> On Sun, Aug 14, 2016 at 10:34 AM, wofritzyt <wolfgan...@gmx.net> wrote:
>> Hi Alex,

<cut>

>
> All I have done to "fix" the issue is to remove the code that set a
> low latency and use the default pulseaudio latency.
>

I tried this too. The underruns go away, but observed situations where
ltenciy went up to 1-2 seconds. I could not find out what the reason was.

> I can imagine there may still be issues if the hardware does not
> support 48 kHz and pulseaudio has to resample. On the other hand, I
> looked in my pulseaudio configuration files and it seems the global
> sample rate is 44.1 kHz, so pulseaudio may in any case be doing a lot
> of resampling.
>
> By the way, the resampler type and quality can also be configured for
> pulseaudio.
>

with "pactl list sink-inputs" I see for the QGRX sink "Resample method:
copy" so I assume that USB stick supports 48kHz sample rate in hardware

> As far as I remember, we have everything in place to support audio
> rates other than 48 kHz. It's just the GUI part that need finishing.
> So that's also an option.
>
>> One "issue" I observe is that the audio data is processed quite "bursty",
>> meaning the FIFO level in my pa_sink implementation sometimes goes very high
>> and sometimes drops to zero, causing an underrun. I don't know the reason
>> for this. Is it gqrx core delivering data too bursty or is i pulse audio
>> requesting data too bursty or is it a non optimal interaction between the
>> gqrx write thread and the pulse audio read thread.
>
> It's the GNU Radio scheduler that determines that, although I think it
> is pretty much driven by how samples are delivered from the input
> source.
>

M< suspicion is that the samples are delivered in bursts and also some
large buffers in the low level drivers that in the end cause the latency.

I am wondering how to measure the latency in the different software
stages. In hardware, I would attach a scope probe to the points I want
to observe (like I did with the overall latency measurement). But how to
do it in software? First step could be logging of data transfers from
the device (chunk sizes and time stamps) which could give an idea how
bursty the data comes from the low level driver. As it seems not to be
very difficult to connect additional blocks to the signal path, could I
attach some kind of level detector at the input and the output of the
gnuradio signal path which logs a time stamp when signal crosses some
threshold? or even send a pulse on some control line of the serial port
that I connect to the scope?

(Just for the laughs: I added a 9 dB amplifier block after the AM
detector because AM audio was much lower than SSB audio)

>
>> BTW, because I have no crackling audio with cubicsdr. I checked the code and
>> the pulse audio sink is basically the same as in gqrx, using pulse audio
>> "simple" API.. But it goes the "safe" way and configures pulse audio buffers
>> for 100ms latency. This is good enough even for my USB stick, but adds quite
>> some latency, so total latency with cubicsdr is 400ms from RF in to AF out
>> which is much more than gqrx.
>
> If it helps, we can add the latency parameter as a configuration
> option. It is also available in the simple API.
>
> While looking into audio issues on the Raspberry Pi, I saw someone
> recommending to comment out the following line in
> /etc/pulse/default.pa:
> load-module module-suspend-on-idle
>
> That had also something to do with crackling, in that the device was
> constantly switched on and off.
>
> By the way, I just tried to see the RF-to-audio latency on my
> computer, using a Funcube Dongle Pro+. It didn't feel like more than
> 50 msec between keying and audio, maybe even less.
>

This is another indication that the main latencies in my system are in
the low level driver part. Unfortunately, this is proprietary software.

The SDRPlay hardware is not bad for the money, but the proprietary
drivers more and more become a problem for me. So I am considering
getting an SDR device which is at least as good as the SDRPlay, but has
fully open source drivers and is known to work well under Linux. Do you
have a recommendation?

Regards,
Wolfgang


> Alex
>

[Alexandru Csete]

On Sun, Aug 14, 2016 at 1:17 PM, Wolfgang Fritz <wolfgan...@gmx.net> wrote:
> Am 14.08.2016 um 12:05 schrieb Alexandru Csete:
>>
>> It's the GNU Radio scheduler that determines that, although I think it
>> is pretty much driven by how samples are delivered from the input
>> source.
>>
>
> M< suspicion is that the samples are delivered in bursts and also some large
> buffers in the low level drivers that in the end cause the latency.

If your computer is fast enough, you could try to printf() the number
of samples that come into the pa_sink::work() function. I have done it
in the past with other blocks and it is actually workable.

> I am wondering how to measure the latency in the different software stages.
> In hardware, I would attach a scope probe to the points I want to observe
> (like I did with the overall latency measurement). But how to do it in
> software? First step could be logging of data transfers from the device
> (chunk sizes and time stamps) which could give an idea how bursty the data
> comes from the low level driver. As it seems not to be very difficult to
> connect additional blocks to the signal path, could I attach some kind of
> level detector at the input and the output of the gnuradio signal path which
> logs a time stamp when signal crosses some threshold? or even send a pulse
> on some control line of the serial port that I connect to the scope?

I think GNU Radio has some features that allow attaching time stamps
to samples and buffers. I have never used them so I have no idea how
they work or what would be involved in using them.

> (Just for the laughs: I added a 9 dB amplifier block after the AM detector
> because AM audio was much lower than SSB audio)

Yes, I suspect it is because many stations have a very low modulation
level compared to the carrier level and it is the carrier level that
drives the AGC. In any case, the AM and FM demodulators are on my TODO
list for a thorough review / rewrite at some point.

>> By the way, I just tried to see the RF-to-audio latency on my
>> computer, using a Funcube Dongle Pro+. It didn't feel like more than
>> 50 msec between keying and audio, maybe even less.
>
> This is another indication that the main latencies in my system are in the
> low level driver part. Unfortunately, this is proprietary software.
>
> The SDRPlay hardware is not bad for the money, but the proprietary drivers
> more and more become a problem for me. So I am considering getting an SDR
> device which is at least as good as the SDRPlay, but has fully open source
> drivers and is known to work well under Linux. Do you have a recommendation?

I found the Airpy + Spyverter to be a very good receiver for HF and it
has a simple, straightforward, open source driver. If you don't need
external clock input or GPIO, then the Airtspy Mini is cheaper and
also works very well.

The HackRF is also quite robust from a driver point of view, but it's
performance on HF is not very good. Good for casual listening and for
testing though.

I also have an RFSpace CloudIQ, which is really a superb receiver, but
the gr-osmosdr driver sometimes has problems establishing a connection
(entirely my fault that I hope to fix soon, the API is open)

I also have and older SDR-IQ that works very well for me, although on
some USB hosts it can not achieve full bandwidth.

I should point out that both Airspy, HackRF and RFSpace have provided
me free hardware in the past, so you should probably not consider me
to be 100% objective. The fact remains though, that the most robust
drivers IMO are also the simplest ones, which are hackrf, airspy and
rtlsdr.

Alex

[Larry Dighera]

On Sun, 14 Aug 2016 15:20:25 +0200, Alexandru Csete <oz9...@gmail.com> wrote:

>I found the Airpy + Spyverter to be a very good receiver for HF and it
>has a simple, straightforward, open source driver. If you don't need
>external clock input or GPIO, then the Airtspy Mini is cheaper and
>also works very well.

February 16, 2016
Review: Airspy vs. SDRplay RSP vs. HackRF
<http://www.rtl-sdr.com/review-airspy-vs-sdrplay-rsp-vs-hackrf/>

Here is the best comparison review of these three products I have seen to date.
Don't overlook the information in the Comments section.

[Alexandru Csete]

On Sun, Aug 14, 2016 at 1:17 PM, Wolfgang Fritz <wolfgan...@gmx.net> wrote:
>>

>> By the way, I just tried to see the RF-to-audio latency on my
>> computer, using a Funcube Dongle Pro+. It didn't feel like more than
>> 50 msec between keying and audio, maybe even less.
>>
>
> This is another indication that the main latencies in my system are in the
> low level driver part. Unfortunately, this is proprietary software.

Hi Wolf,

I borrowed and SDRPlay receiver and set it up through the SoapySDR
API. It seems to work well and I repeated my test keying the
transmitter and didn't notice any significant latency. The only thing
I noticed is that at some sample rates the audio FFT refresh rate was
low.

If you want we can do a more detailed comparison of our systems.
Basically, I am running Xubuntu 14.04 64 bit.

Alex

[Wolfgang Fritz]

Am 17.08.2016 um 22:19 schrieb Alexandru Csete:
> On Sun, Aug 14, 2016 at 1:17 PM, Wolfgang Fritz <wolfgan...@gmx.net> wrote:
>>>
>>> By the way, I just tried to see the RF-to-audio latency on my
>>> computer, using a Funcube Dongle Pro+. It didn't feel like more than
>>> 50 msec between keying and audio, maybe even less.
>>>
>>
>> This is another indication that the main latencies in my system are in the
>> low level driver part. Unfortunately, this is proprietary software.
>
> Hi Wolf,
>
> I borrowed and SDRPlay receiver and set it up through the SoapySDR
> API. It seems to work well and I repeated my test keying the
> transmitter and didn't notice any significant latency. The only thing
> I noticed is that at some sample rates the audio FFT refresh rate was
> low.
>

That's interesting. I have noticed slow FFT updates sometines too, but
only very short ones so I thought it was some graphics lag on my laptop
(and this actually might be the case)

> If you want we can do a more detailed comparison of our systems.
> Basically, I am running Xubuntu 14.04 64 bit.
>

This is a HP EliteBook 8560p Notebook with Intel(R) Core(TM) i5-2540M
CPU (from /proc/cpuinfo). I am running Kubuntu 16.04 64 bit.

There are issues with SDRPlay on 16.04. I get a complete freeze (only 5
seconds power button helps to recover) when I try to use the SDRPlay wit
a USB 2.0 port. USB 3.0 is working, but maybe not correctly.

BTW, I was not able to run the SDRPlay with full bandwidth due to USB
timeouts. This happened with 14.04 and 16.04.

I still have Kubuntu 14.04 on this Notebook. I'll try to do some delay
measurements with 14.04 this weekend.

Thanks a lot for your support.

Wolfgang

> Alex
>