Gqrx and RPi 3b

[Bob Johnson]

I have Gqrx running on a RPi 3b Rasbian and can copy amateur radio packet using the built in AFSK program. But I cannot get the output of Gqrx to the input of Fldigi, which I need to copy some satellite signals. Is there a way to link pulseAudio from the output of the SDR radio to digital software such as Fldigi?  I have searched and cannot find a definitive answer. 

any help is much appreciated.

bob

[Alexandru Csete]

Hi Bob,

You can use pavucontrol to set fldigi to read audio from the output
instead of an input, see
http://www.pe0sat.vgnet.nl/decoding/unix-tlm-decoding/

Alex

[jmly...@gmail.com]

Bob:

Pulse Audio Volume Control was not installed by default on my Ubuntu 14.04LTS system. You might have to install it from the software center.

James
 

[Ldighera]

Hello Bob,

Congratulations on getting gqrx running under Debian Jessie on your Raspberry Pi 3.  I have built gqrx on that platform also, but am encountering issues with the audio output.  Gqrx seems to control the Airspy Mini with Spyverter or the RTL-SDR okay, but the audio is poor and sounds like a motorboat.  Strong signals do change the character of the audio, but it's nothing resembling voice.

I built gqrx from the latest source on github.com and installed the gnuradio Version 3.7.5 package with apt-get.  I'm wondering if the audio issue is a result of not building gnuradio from the latest source code?

Additionally, I'm experiencing over heating despite fan cooling the RPi.  Currently, I'm (over)clocking the CPU at 900 MHz.  :-)

I would be most grateful for any clues you might be able to offer.

ADVthanksANCE

Best regards,
Larry Dighera
WB6BBB

[Alan Corey]

Me too :)  I installed the Gnuradio 3.7.5-5 from the debs with Synaptic, then built Gqrx from the gqrx-sdr-src-2.5.3.tar.xz tarball.

The GUI comes up but when I turn on DSP I get:

gr::log :ERROR: audio_alsa_sink0 - [default]: snd_pcm_sw_params: Invalid
argument
terminate called after throwing an instance of 'std::runtime_error'
  what():  audio_alsa_sink
Aborted

I have locate installed and I've run updatedb, but I can't even find an audio_alsa_sink anywhere, as a file, or see one in GRC.  Do I need to build Gnuradio from source?

[Alexandru Csete]

On Fri, Jul 1, 2016 at 7:23 PM, Alan Corey <alan...@gmail.com> wrote:
> Me too :) I installed the Gnuradio 3.7.5-5 from the debs with Synaptic,
> then built Gqrx from the gqrx-sdr-src-2.5.3.tar.xz tarball.
>
> The GUI comes up but when I turn on DSP I get:
>
> gr::log :ERROR: audio_alsa_sink0 - [default]: snd_pcm_sw_params: Invalid
> argument
> terminate called after throwing an instance of 'std::runtime_error'
> what(): audio_alsa_sink
> Aborted
>
>
> I have locate installed and I've run updatedb, but I can't even find an
> audio_alsa_sink anywhere, as a file, or see one in GRC. Do I need to build
> Gnuradio from source?

No, not at all. The error means something is wrong with the parameters
passed to ALSA. Try to enter an audio device other that the default,
e.g. "hw:0"

Alex

[Alan Corey]

Interesting, I just found that I can actually get a moving waterfall as long as the demodulator is off, it doesn't matter what the audio device is.  Then when I select narrow FM or AM with DSP on it crashes.  Turn off DSP, pick narrow FM, turn on DSP: crash.  So maybe it's something like a sample rate mismatch?  Those usually aren't fatal.

For Alsa devices I see:

**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Running it looks like this, but I don't know why there are no peaks except in the waterfall.  I use the local weather radio transmitters as test signals often, this looks reasonable.

It makes me uneasy that in GRC I don't see an audio_alsa_sink, or many other things I'm used to seeing.  I've built Gnuradio from sources before and I remember that when dependencies aren't met, things aren't built.  A typical build farm might not have noticed.

[Adrian Musceac]

Hi,

are you running through pulseaudio or straight into Alsa?
I have gnuradio running just fine on my Android phone, but I had to tweak the pulseaudio settings a lot to get it working (Debian Jessie).

Cheers,
Adrian

On 2 July 2016 17:41:25 GMT+01:00, Alan Corey <alan...@gmail.com> wrote:
>
>
><https://lh3.googleusercontent.com/-ZBXFqd2b_VE/V3fuLtw5kOI/AAAAAAAAAko/2fkKbXUsqbk4qqa2N2L1xBN2MzPxu9u4QCLcB/s1600/wf_no-peaks2.jpg>

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

[Larry Dighera]

Hello Alan,

Gqrx version 2.5.3-37-g795e8be runs on my RPi3 under Debian Jessie (noobs) with
Airspy Mini & Spyverter connected, and produces a smooth waterfall. To provide
gqrx all the CPU cycles possible, I over-clock the RPi CPU with this entry in
/boot/config.txt: arm_freq-1100; higher frequencies seem to affect system
reliability. To overcome RPi overheating, it was necessary to install a fan
<https://www.amazon.com/gp/product/B00YBS1010>; in my opinion, a fan is a
requirement for the RPi3 with its chips stacked. I kill the apache daemon
(apache2ctl stop) and teamviewer daemon (teamviewer --daemon stop) to reduce
CPU load further.

Launching gqrx produces this message: libegl: Warning: DIR2: Failed to
authenticate (Some info here: <https://pi3d.github.io/html/FAQ.html>.), but
gqrx runs with 90-98% CPU loading when I click Start. PulseAudio is configured
with Sinks: bcm2835 ALSA Analog Stereo, and Sources:
ALSA_output.0.analog-stereo-monitor. Unfortunately, the audio stutters to the
point of being completely unintelligible. Recording audio with gqrx succeeds
sometimes producing a .wav file that is playable with ALSA (aplay), but
recording usually locks up gqrx.

So gqrx will produce near real-time spectrum/waterfall display (unlike CubicSDR
that has significant delay between mouse input and display response). Don't
give up.

The audio issue, on the other hand, is probably going to be difficult to
workaround, as CubicSDR audio is poor, although it doesn't stutter. I'm
leaning toward pointing the finger at PulseAudio as the source of the sound
issue with gqrx. It would be nice to see how gqrx's audio performance on the
RPi3 would be affected if ALSA audio was an alternative option, in additional
to the current PulseAudio option.

Best regards,
Larry
WB6BBB


PS: Is anyone able to offer a clue on how to enable the Spyverter up-converter
with gqrx for HF support? I believe it's just a matter of setting the correct
negative value for the LO, but the AirSpy web site provides precious little
documentation ...




On Sat, 2 Jul 2016 09:41:25 -0700 (PDT), Alan Corey <alan...@gmail.com>
wrote:

[Alan Corey]

Frankly I don't know, I thought it wanted Alsa.  But I installed a couple PulseAudio things like pavucontrol and now I see peaks.  Still crashes when I try to demodulate anything.  My config looks like this:

[General]
crashed=true
configversion=2

[input]
device="rtl=0"
bandwidth=1800000
sample_rate=2400000
frequency=162500000
gains=@Variant(\0\0\0\b\0\0\0\x1\0\0\0\x6\0L\0N\0\x41\0\0\0\x2\0\0\x1\x12)
corr_freq=59000000

[gui]
geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x1\0\0\0\0\0\x1d\0\0\0\0\0\0\x3\xd2\0\0\x2t\0\0\0\x1d\0\0\0\0\0\0\x3\xd2\0\0\x2t\0\0\0\0\0\0)
state=@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x2\0\0\0\x1\0\0\x1\x16\0\0\x2!\xfc\x2\0\0\0\x2\xfc\0\0\0>\0\0\x1S\0\0\x1S\0\b\0\x1c\xfa\0\0\0\x1\x2\0\0\0\x3\xfb\0\0\0\x18\0\x44\0o\0\x63\0k\0I\0n\0p\0u\0t\0\x43\0t\0l\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\xee\0\xff\xff\xff\xfb\0\0\0\x12\0\x44\0o\0\x63\0k\0R\0x\0O\0p\0t\x1\0\0\0\0\xff\xff\xff\xff\0\0\x1\x36\0\a\xff\xff\xfb\0\0\0\xe\0\x44\0o\0\x63\0k\0\x46\0\x66\0t\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\xc8\0\a\xff\xff\xfc\0\0\x1\x97\0\0\0\xc8\0\0\0\xc8\0\xff\xff\xff\xfa\0\0\0\0\x2\0\0\0\x2\xfb\0\0\0\x12\0\x44\0o\0\x63\0k\0\x41\0u\0\x64\0i\0o\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\xc8\0\xff\xff\xff\xfb\0\0\0\xe\0\x44\0o\0\x63\0k\0R\0\x44\0S\0\0\0\0\0\xff\xff\xff\xff\0\0\0h\0\xff\xff\xff\0\0\0\x3\0\0\0\0\0\0\0\0\xfc\x1\0\0\0\x1\xfb\0\0\0\x1a\0\x44\0o\0\x63\0k\0\x42\0o\0o\0k\0m\0\x61\0r\0k\0s\0\0\0\0\0\xff\xff\xff\xff\0\0\x1\x42\0\xff\xff\xff\0\0\x2\x9a\0\0\x2!\0\0\0\x1\0\0\0\x2\0\0\0\b\0\0\0\x2\xfc\0\0\0\x1\0\0\0\x2\0\0\0\x1\0\0\0\x16\0m\0\x61\0i\0n\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0)

[receiver]
demod=0
offset=3000

[audio]
gain=-200
rec_dir=
udp_host=
udp_port=65535

[fft]
averaging=49
split=51
fft_size=32768
fft_range=128

I'm not about to overclock anything, it's not that important.  I'd work at pruning out excess bloatware instead.  I'm surprised the Pi 3 can run Gnuradio, I'm not a Python fan.

I'd like to work at a program to bridge rtl_tcp with Lysdr, something which sticks to compiled efficient code.  rtl_power gathers data at about 2% CPU for example.

Interesting on the Android, is that an Android app or are you running this under Linux?  My phone with Linux installed doesn't do OTG so I didn't try Gnuradio.  The one with OTG I haven't rooted and put Linux on yet.

[Alexandru Csete]

Gqrx uses pulseaudio by default but it can be compiled to use gr-audio
instead, which in turn can use ALSA, portaudio, OSS, or whatever audio
system is available on the platform.

The error message in your first mail came from gr-audio and it looked
like it was using the ALSA backend - otherwise it wouldn't have
printed audio_alsa_sink0 as source of the error. In gnuradio-companion
you will not see "ALSA", just "Audio sink".

As I suggested in my first reply, you should try specifying a correct
ALSA audio device like hw:0

What exactly do you mean by gqrx crashing? To me crash means the
application terminates abnormally, but you wrote something about
changing mode after the program crashed?

On a more general note, gnuradio installed from the Raspbian
repository is built with NEON instructions disabled, so it will lack
important optimizations, see https://brmlab.cz/user/jenda/rpi-gcc

But if you are close and it is almost running you may get the missing
cpu cycles by reducing the sample rate, fft size and fft rate.

Alex

> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/1698ac2f-690d-4d6a-8a42-f76d1b76b306%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[David Ranch]

I don't think an Rpi v3 is up to the task to handle 10MSPS but maybe if you drop it down, it will work better.  Worth a try.  As for your spyverter question, see:


Yes, I have it working here.  See:

   http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#42k.using-gqrx

--
      - Airspy R2:

          - Device String:
               airspy=0,bias=0

          - The above "bias=1" would be used to power the SpyVerter from the AirSpy
             - If you do enable the Spyverter, also change the "LNB LO" to
               -120.000000 MHz  (yes, that's negative 120Mhz)

          - To Change the Gain mode:
               Sensitivity:  airspy_set_sensitivity_gain
               Linearity:    airspy_set_linearity_gain
--

--David
KI6ZHD

[Larry Dighera]

Hello David,

Thank you very much for your response. Just what I was hoping for.

My comments in-line below:

On Sat, 2 Jul 2016 16:59:48 -0700 (PDT), David Ranch <dra...@gmail.com> wrote:

>
>I don't think an Rpi v3 is up to the task to handle 10MSPS but maybe if you
>drop it down, it will work better. Worth a try.
>

The Airspy Mini specification <http://airspy.com/airspy-mini/> indicates that
it will sample at 10, 6, and 3 MSPS, however in the gqrx Configure I/O Devices
dialog window the Airspy Mini sampling can be set to 2.5 MSPS.

>
>As for your spyverter question, see:
>

Thank you for the link to this document.

>
>Yes, I have it working here. See:
>
>
>http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#42k.using-gqrx
>
>--
>

I found that the settings below are done in the gqrx Configure I/O Devices
dialog window:

> - Airspy R2:
>
> - Device String:
> airspy=0,bias=0
>
> - The above "bias=1" would be used to power the SpyVerter from
>the AirSpy
> - If you do enable the Spyverter, also change the "LNB LO" to
> -120.000000 MHz (yes, that's negative 120Mhz)
>

I did that, and was able to get gqrx to tune the HF spectrum. However, I
didn't see any signals on the spectrum/waterfall displays. This may be because
I didn't find where to make the settings below:

>
> - To Change the Gain mode:
> Sensitivity: airspy_set_sensitivity_gain
> Linearity: airspy_set_linearity_gain
>--
>
>--David
>KI6ZHD

Are those settings done with the less than well documented Airspy Tools
<https://github.com/airspy/host/tree/master/airspy-tools>, in the gqrx
Configure I/O Devices dialog window, or someplace else?

Lack of intelligible sound is still an issue also, it sounds like someone
fanning a deck of cards. Could the decimation setting, as mentioned at the
bottom of this page <http://airspy.com/quickstart/> be of help with the sound
issue?

I'm very grateful for your assistance. Thank you.

Best regards,
Larry

[Larry Dighera]

Hello Adrian,

I'm close to getting a usable gqrx running on the Raspberry Pi3 under Debian
Jessie using both the Airspy Mini and alternatively the RTL-SDR dongle, and
having issues with sound output. The sound is like someone fanning a deck of
cards.

I'd be grateful for any insight you may be able to provide in attempting to
overcome the sound issue.

Best regards,
Larry

[Alexandru Csete]

On Sun, Jul 3, 2016 at 2:45 PM, Larry Dighera <LDig...@att.net> wrote:
>
> The Airspy Mini specification <http://airspy.com/airspy-mini/> indicates that
> it will sample at 10, 6, and 3 MSPS, however in the gqrx Configure I/O Devices
> dialog window the Airspy Mini sampling can be set to 2.5 MSPS.

Since the Airspy Mini is very new, gqrx can not yet see any difference
between the mini and the original. So, gqrx will only show 10 Msps and
2.5 Msps but you can enter any value here. And you *must* enter either
6 or 3 Msps otherwise the signal processing will run at 2.5 Msps while
the device itself will run at 3 Msps.

Alex

[Alan Corey]

Is there some syntax with which I can specify a default Alsa device in ~/.config/gqrx/default.conf?  The only place I can find to change it is by typing it into a GUI pulldown which probably doesn't do anything.  With some toolkits in some programs it does.  That pulldown list is only populated with "Default" in my case, backspacing it and entering hw:0 doesn't seem to accomplish anything.

By crash I mean the GUI going off the screen and getting a crashed=true line in the config file.  I can change demodulation modes only when the DSP is off.  I tried to set minimally demanding numbers in this screenshot, but still if the DSP toggle is on with any demodulation other than "Demod Off" selected it crashes.

[Alexandru Csete]

You can enter "device=hw:0" in the audio section (without quotes) but
it will probably not make any difference either.

Alex

[Alan Corey]

Right, no difference.  It doesn't show in the GUI dialog box either.  I even tried device="hw:0" to enclose the colon.  But other people are having different results.  I'm using
Linux raspberrypi 4.4.13-v7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux
and my GCC is
gcc (Raspbian 4.9.2-10) 4.9.2

gqrx is from a downloaded tarball, gnuradio is from debs

Just an aside, rtl_tcp is sitting here on my Pi 3b at < 5% CPU feeding HDSDR running on another machine over ethernet.  You could put the pi and dongle at the antenna and run up to 100 meters of cat5 wire.  A Pi Zero might even work.  I'm still waiting on some adapters for mine.

[Alan Corey]

Low everything remote scan from ideas at http://kmkeen.com/rtl-demod-guide/2013-01-02-17-54-37-499.html

On my Pi I'm running a script:
rtl_fm -l 64 -M fm -p 59 -s 24k -f 854038000 -f 854413000 -f 854313000  \
- | sox -traw -r24k -es -b16 -c1 -V1 - -tmp3 - | socat -u - TCP-LISTEN:8080

And on my laptop I'm running:
nc 192.168.0.16 8080 | play -t mp3 -

Rtl_fm scans, feeds audio to sox which makes it into an mp3 stream and sends it using socat on the Pi.  On the laptop nc (netcat) listens to the Pi's IP address, feeds the stream to play (sox).  5% CPU on the Pi, can't measure it on the playback end or the network bandwidth used by the compressed audio stream.  Sensitive to dropped connections though, I have to restart both scripts.  Off topic but I just got it working so I'm excited.

[Adrian Musceac]

Hi Larry,

What I'm about to describe only applies if you are using Pulseaudio as a sound server and not if you are talking directly to an Alsa device.

First of all, Pulseaudio has many useful features, but that also adds to the load on the system, so if you are very constrained on resources, you might be better off disabling many of the default modules in /etc/pulse/default.pa

 and in extreme cases maybe also disabling module-udev-detect and loading the alsa modules explicitly:
load-module module-alsa-sink device=hw:0,0
load-module module-alsa-source device=hw:0,0

Also, you should note that Pulseaudio will try to match the sound rate you get from Gqrx as closely as possible with what the Alsa device requires. Even a minor difference in sample rates can trigger resampling within Pulseaudio, and this is a very computationally expensive feature.

The most important tweak here to be made is changing resample-method

 in /etc/pulse/daemon.conf to something like "resample-method = ffmpeg" which is the most efficient resample method, although you may experience problems with stereo or mono sounds.

A fallback method is speex-fixed-2 which has better quality and will not mangle your waveform as much.

Try to carefully monitor the CPU usage of Pulseaudio and if necessary reduce the default-sample-rate as well until you have manageable load. If you don't care very much about high frequency components in the audio signal, you can drop the audio sample rate to 8000 (which should be supported by most Alsa cards).

THis will further improve your performance.

Hope this helps,

Adrian

--
You received this message because you are subscribed to the Google Groups "Gqrx SDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gqrx+uns...@googlegroups.com.
To post to this group, send email to gq...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gqrx/ke2inbp4sbi8342gmsc1r4rnl5a3p7fuk1%404ax.com.

[Larry Dighera]

Hello Adrian,

Thank you very much for your detailed response to my inquiry. Very much
appreciated.

From the information you have kindly provided, I think we may be on the right
track to getting gqrx audio operational on my RPi3 platform.

I'll give your suggestions a try, and report back here with my experiences.

Best regards,
Larry

[Alexandru Csete]

On Sun, Jul 3, 2016 at 4:08 PM, Alan Corey <alan...@gmail.com> wrote:
>
> Is there some syntax with which I can specify a default Alsa device in ~/.config/gqrx/default.conf? The only place I can find to change it is by typing it into a GUI pulldown which probably doesn't do anything. With some toolkits in some programs it does. That pulldown list is only populated with "Default" in my case, backspacing it and entering hw:0 doesn't seem to accomplish anything.

You can try again with the latest code from git. I just merged a patch
that fixes this bug:
https://github.com/csete/gqrx/pull/390

Alex

[Larry Dighera]

Hello Adrian,

I've finally found the time to begin to implement the suggestions you kindly
provided. This is a sort of quick interim report of that effort.

As you suggested, I commented out as many modules in /etc/pulse/
default.pa as I thought appropriate, and changed to statically loading the alsa
modules with no discernable improvement.

Here is the display of CPU use from top:

====================================================================
top - 17:40:03 up 1:52, 2 users, load average: 8.02, 4.38, 1.81
Tasks: 151 total, 2 running, 149 sleeping, 0 stopped, 0 zombie
%Cpu(s): 71.5 us, 19.2 sy, 0.0 ni, 6.0 id, 0.0 wa, 0.0 hi, 3.3 si, 0.0 st
KiB Mem: 882788 total, 432156 used, 450632 free, 30520 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 209380 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2035 root 20 0 671936 138964 62224 R 321.2 15.7 12:44.41 gqrx
1910 root 9 -11 201604 60176 44484 S 38.4 6.8 1:43.78 pulseaudio
1767 root 19 -1 122344 43968 22048 S 7.9 5.0 0:26.40 Xorg
1518 root 20 0 0 0 0 S 1.0 0.0 0:01.99
kworker/u8:1
5 root 0 -20 0 0 0 S 0.7 0.0 0:01.43
kworker/0:0H
2335 root 20 0 5112 2552 2168 R 0.7 0.3 0:00.05 top
7 root 20 0 0 0 0 S 0.3 0.0 0:01.91 rcu_sched
11 root 20 0 0 0 0 S 0.3 0.0 0:00.11 ksoftirqd/1
71 root 1 -19 0 0 0 S 0.3 0.0 0:01.36 VCHIQ-0
78 root -51 0 0 0 0 S 0.3 0.0 0:02.37 irq/92-mmc1
134 root 20 0 9540 2920 2636 S 0.3 0.3 0:00.82
systemd-journal
246 root 20 0 0 0 0 S 0.3 0.0 0:00.95
brcmf_wdog/mmc1
====================================================================

I attempted to change the resample-method to ffmpeg in /etc/pulse/daemon.conf,
and found that the ffmpeg package isn't installed. I'm unclear about loading
ffmpeg given this information:

====================================================================
/root (1) # show.sh ffmpeg
Package: ffmpeg
Status: deinstall ok config-files
Priority: optional
Section: video
Installed-Size: 1702
Maintainer: Debian Multimedia Maintainers
<pkg-multimedi...@lists.alioth.debian.org>
Architecture: armhf
Multi-Arch: foreign
Version: 7:2.8.6-1~bpo8+1
Replaces: libav-tools (<< 6:12~~), qt-faststart (<< 7:2.7.1-3~)
Depends: libavcodec-ffmpeg56 (>= 7:2.7) | libavcodec-ffmpeg-extra56
(>= 7:2.7), libavdevice-ffmpeg56 (>= 7:2.6), libavfilter-ffmpeg5 (>=
7:2.4), libavformat-ffmpeg56 (>= 7:2.6), libavresample-ffmpeg2 (>=
7:2.4), libavutil-ffmpeg54 (>= 7:2.5), libc6 (>= 2.4),
libpostproc-ffmpeg53 (>= 7:2.4), libsdl1.2debian (>= 1.2.11),
libswresample-ffmpeg1 (>= 7:2.4), libswscale-ffmpeg3 (>= 7:2.4),
libvdpau1 (>= 0.2), libx11-6
Suggests: ffmpeg-doc
Breaks: libav-tools (<< 6:12~~), qt-faststart (<< 7:2.7.1-3~)
Conffiles:
/etc/ffserver.conf newconffile
Description: Tools for transcoding, streaming and playing of multimedia files
FFmpeg is the leading multimedia framework, able to decode, encode, transcode,
mux, demux, stream, filter and play pretty much anything that humans and
machines have created. It supports the most obscure ancient formats up to the
cutting edge.
.
This package contains:
* ffmpeg: a command line tool to convert multimedia files between formats
* ffserver: a multimedia streaming server for live broadcasts
* ffplay: a simple media player based on SDL and the FFmpeg libraries
* ffprobe: a simple multimedia stream analyzer
* qt-faststart: a utility to rearrange Quicktime files
Description-md5: 032ff4ee68b923f5137379a7857cb8a8
Homepage: https://ffmpeg.org/
------------

/root (1) # get.sh ffmpeg
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package ffmpeg is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'ffmpeg' has no installation candidate
====================================================================

The ffmpeg package doesn't seem to be available from the default Debian
repositories. I'm going to have to do some investigation into the issues
mentioned above about breaking "libav-tools (<< 6:12~~), qt-faststart (<<
7:2.7.1-3~)" later, as time permits.

I'll provide a more complete report soon.

Thank you for your assistance.

Best regards,
Larry


On Mon, 4 Jul 2016 19:13:14 +0100, Adrian Musceac <kant...@gmail.com> wrote:

[Adrian Musceac]

Hi Larry,
you can replace ffmpeg with speex-fixed-2 meanwhile.

regards,
Adrian

[Larry Dighera]

Hello Adrian,

I built ffmpeg, and despite many warnings, it seems to function okay, so I
enabled it in /etc/pulse/deamon.conf as you suggested. I also set the sample
rate to 8k, and gqrx' audio output is slightly improved, and the CPU load is
reduced to ~90%. The rate of what sounded like a deck of cards being fanned,
now sounds like the cards are being fanned faster, and it is almost possible to
discern the content of the signal's audio. FM-Mono performed slightly better
than FM-Stereo on broadcast FM, and AM and NFM are slightly improved, but still
far from intelligible. So your suggestions are marginally improving
performance.

I also tried reducing the pulseaudio sample rate to 4k, but it didn't seem to
have any effect. Then I reduced the RPi3's CPU clock from 1100 to 800, and
heard no audio at all, so I increased the CPU clock rate to 1200, and that
seemed to perform about the same as 1100. (Past tests have shown that a CPU
clock rate of 1300 fails to boot.)

Here's a 'top' dump:

==========================
Tasks: 161 total, 3 running, 158 sleeping, 0 stopped, 0 zombie
%Cpu(s): 66.3 us, 20.6 sy, 0.0 ni, 10.6 id, 0.0 wa, 0.0 hi, 2.5 si, 0.0 st
KiB Mem: 882788 total, 600232 used, 282556 free, 39576 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 336376 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

3162 root 20 0 571740 139264 62460 S 288.0 15.8 2:09.44 gqrx 2276
root 9 -11 221024 65528 30160 S 44.8 7.4 7:39.86 pulseaudio 136
root 20 0 9540 4332 4048 S 6.9 0.5 4:42.02 systemd-jo+ 598
root 20 0 32144 3168 2380 S 5.6 0.4 2:04.42 rsyslogd 1402
root 19 -1 129132 50072 21824 R 4.6 5.7 1:09.67 Xorg 1642 root
20 0 48856 20464 16796 S 1.3 2.3 0:24.42 lxterminal 3310 root 20
0 5240 2596 2144 R 1.0 0.3 0:00.07 top 7 root 20 0 0
0 0 S 0.3 0.0 0:15.30 rcu_sched 72 root 1 -19 0 0
0 S 0.3 0.0 0:05.60 VCHIQ-0
...
==========================

Here's the output from pulseaudio --dump-conf

==========================================================
### Read from configuration file: /etc/pulse/daemon.conf ###
daemonize = no
fail = yes
high-priority = yes
nice-level = -11
realtime-scheduling = yes
realtime-priority = 5
allow-module-loading = yes
allow-exit = yes
use-pid-file = yes
system-instance = no
local-server-type = user
cpu-limit = no
enable-shm = yes
flat-volumes = yes
lock-memory = no
exit-idle-time = 20
scache-idle-time = 20
dl-search-path = /usr/lib/pulse-5.0/modules
default-script-file = /etc/pulse/default.pa
load-default-script-file = yes
log-target =
log-level = notice
resample-method = ffmpeg
enable-remixing = yes
enable-lfe-remixing = no
default-sample-format = s16le
default-sample-rate = 8000
alternate-sample-rate = 8000
default-sample-channels = 2
default-channel-map = front-left,front-right
default-fragments = 4
default-fragment-size-msec = 25
enable-deferred-volume = yes
deferred-volume-safety-margin-usec = 8000
deferred-volume-extra-delay-usec = 0
shm-size-bytes = 0
log-meta = no
log-time = no
log-backtrace = 0
rlimit-fsize = -1
rlimit-data = -1
rlimit-stack = -1
rlimit-core = -1
rlimit-rss = -1
rlimit-as = -1
rlimit-nproc = -1
rlimit-nofile = 256
rlimit-memlock = -1
rlimit-locks = -1
rlimit-sigpending = -1
rlimit-msgqueue = -1
rlimit-nice = 31
rlimit-rtprio = 9
rlimit-rttime = 1000000
/etc/pulse (/dev/pts/1) #
==========================================================

Perhaps you may spot some other pulseaudio candidate parameters to modify.

Also, here is gqrx's startup message:

=============================
# /root/radio/gqr*/build/src/gqrx
linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0-unknown

libEGL warning: DRI2: failed to authenticate
gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy
Using Volk machine: neon_hardfp_orc
BookmarksFile is /root/.config/gqrx/bookmarks.csv
gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy
Using AIRSPY with firmware AirSpy MINI v1.0.0-rc7-0-gc2b2bbe 2016-
=============================

Gqrx has the audio sample rate fixed at 48000 in the pop-up device window; can
that be changed in the gqrx .xml configuration file?

I have found that changing the pulseaudio sample rate to 4000 in the
daemon.conf file helps a bit.

So, in summary, increasing the RPi3's CPU clock rate appears to be imperative.
Reducing pulseaudio's sample rate in enabling ffmpeg resampling method provide
some small improvement in gqrx's audio on the RPi3 under Debian Jessie.

I'm using the Debian repository gnu-radio package, but have heard that the
current gnu-radio version has improved performance. I've attempted to build
gnu-radio, and succeeded by using the -k (keep going) make switch to bet beyond
the fatal error (see below). I'll look into this build, as I am at a loss as
to what else may enable gqrx to run on the RPi3.

I can't thank you enough for your sharing your success methods with gqrx on
marginal hardware, and am grateful for your patience and personal assistance.

Best regards,
Larry


PS:
The change to ffmpeg resample method and 8k sample rate resulted in gqrx's
usual "fanned card deck" sound increasing in "number of card falls per second"
with some little intelligibility of audio content. FM-Mono performed slightly
better than FM-Stereo.
====================

Tasks: 161 total, 3 running, 158 sleeping, 0 stopped, 0 zombie
%Cpu(s): 66.3 us, 20.6 sy, 0.0 ni, 10.6 id, 0.0 wa, 0.0 hi, 2.5 si, 0.0 st
KiB Mem: 882788 total, 600232 used, 282556 free, 39576 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 336376 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

3162 root 20 0 571740 139264 62460 S 288.0 15.8 2:09.44 gqrx 2276
root 9 -11 221024 65528 30160 S 44.8 7.4 7:39.86 pulseaudio 136
root 20 0 9540 4332 4048 S 6.9 0.5 4:42.02 systemd-jo+ 598
root 20 0 32144 3168 2380 S 5.6 0.4 2:04.42 rsyslogd 1402
root 19 -1 129132 50072 21824 R 4.6 5.7 1:09.67 Xorg 1642 root
20 0 48856 20464 16796 S 1.3 2.3 0:24.42 lxterminal 3310 root
20 0 5240 2596 2144 R 1.0 0.3 0:00.07 top 7 root 20 0
0 0 0 S 0.3 0.0 0:15.30 rcu_sched 72 root 1 -19 0
0 0 S 0.3 0.0 0:05.60 VCHIQ-0 ==========================

I had built gqrx with the cmake version 3.0.2 available from the Debian
repository, and came across a note that indicated that cmake version >=3.2.0
was required, so I built cmake and gqrx, but make reported this failure despite
producing the gqrx executable:

==========================================================
...
[ 90%] Generating wxgui_swig.pyo
[ 90%] Built target pygen_gr_wxgui_swig_3eebd
Makefile:147: recipe for target 'all' failed
==========================================================

and this:

===================================================================
...
[ 92%] Building CXX object
src/CMakeFiles/gqrx.dir/pulseaudio/pa_device_list.cc.o
/root/radio/gqrx.git/src/pulseaudio/pa_device_list.cc: In member function
‘int pa_device_list::populate_device_list()’:
/root/radio/gqrx.git/src/pulseaudio/pa_device_list.cc:129:49: warning:
‘pa_op’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (pa_operation_get_state(pa_op) == PA_OPERATION_DONE) {
^
[ 93%] Building CXX object src/CMakeFiles/gqrx.dir/pulseaudio/pa_sink.cc.o
=====================================================================

and now receive this message upon starting gqrx:

==========================================================
/root (/dev/pts/0) # /root/radio/gqr*/build/src/gqrx
linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0-unknown

libEGL warning: DRI2: failed to authenticate
gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy
Using Volk machine: neon_hardfp_orc
BookmarksFile is /root/.config/gqrx/bookmarks.csv
gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy
Using AIRSPY with firmware AirSpy MINI v1.0.0-rc7-0-gc2b2bbe 2016-
==========================================================
But no audio at all.

I've almost successfully built the latest version of gnu-radio (supposed to
have improved performance over the package distributed by Debian), with the
exception of this at 90%:

=================================================
...
[ 90%] Built target _wxgui_swig
Scanning dependencies of target pygen_gr_wxgui_swig_3eebd
[ 90%] Generating wxgui_swig.pyc
[ 90%] Generating wxgui_swig.pyo
[ 90%] Built target pygen_gr_wxgui_swig_3eebd
Makefile:147: recipe for target 'all' failed
==================================================

If I could get the improved performance of the latest gnu-radio, I'm hoping it
may improve gqrx audio, but I have no clue how to resolve the issue above.

[Adrian Musceac]

Hi Larry,
I see you already have gnuradio running with hardfp-orc optimizations, so compiling from source is unlikely to improve things. Also, 4000 as a sample.rate will just lead to upsampling in Pulseaudio since most cards can't handle anything below 8000.

If you're comfortable diving into the code of Gqrx, you could go and tweak all the filters in the chain. This will have a dramatic effect since a sharper filter with more taps will take a lot more iterations and CPU cycles.

cheers,
Adrian

[David Ranch]

Hello Larry,

Nice work on recompiling things and digging into the deep underworld that is PulseAudio!  Few things struck me in this thread worth mentioning:

   1. You need to get the gnuradio build failures fixed.  I think the error you cited is actually just a warning and you needed to scroll up farther to find the real failure (Cmake building things in parallel really makes this harder than it should).  I feel your pain here as compiling GnuRadio is a brutal process (takes forever) and really takes a computer to it's knees.  I see you're running 3.7.5 though 3.7.9.2 is current. 


   2. Have you run the Volk optimizations?   In my doc (http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#42b3.gnuradio-installing) , I recommend to reboot your Rpi, log in as yourself, and run:
--
   # takes 18min 22sec on a i5-2430M running 2.4Ghz w/ 4GB RAM - only uses a single core
   time volk_profile
--

That step will take a long time on an Rpi but will make sure GnuRadio optimizes as fast as possible


   3. The Broadcom SOC chip *will* throttle itself if it gets hot and at that point, all bets are off for performance.  How do you have your Rpi mounted (in a case, etc)?  Is it in a case with good ventilation?  Do you have 3rd party heat sinks on it that might have poor thermal pads?  Is there a fan on it that's not turning?  You might want to add a temp monitoring program to your Rpi to watch it - https://www.google.com/search?q=raspberry+pi+CPU+temp+monitoring


   4. You're struggling to match sample rates to what your soundcard supports.  I've personally found that unless your soundcard NATIVELY supports lower rates, Linux's built-in automatic resampling takes even more CPU.  Most modern sound cards have dropped lower sample rates and just do 48Khz or maybe 44.1Khz.  Per the #42a.quisk section of my doc, I recommend to use the alsa-info tool which makes this easy but it seems that program isn't available in Raspian Jessie (grr!!!!).  Instead, try this approach which I found on the web:

--
 #From https://lacocina.nl/detect-alsa-output-capabilities
 #
 bash <(wget -q -O - "http://lacocina.nl/alsa-capabilities") -l usb -s

 0) USB Audio Class Digital alsa audio output interface `hw:1,0'
 - device name       = C-Media USB Audio Device
 - interface name    = USB Audio
 - usb audio class   = 1 - isochronous adaptive
 - character device  = /dev/snd/pcmC1D0p
 - rates per format  = S16_LE:              48000Hz 44100Hz  <--------------------------------------
 - monitor file      = /proc/asound/card1/pcm0p/sub0/hw_params
 - stream file       = /proc/asound/card1/stream0
--

As you can see here, my Syba USB sound card only supports 48k and 44.1k.  Anything less than that will require the ALSA system to resample the audio which requires MORE work.  Maybe resampling to 16k will be less overall work than GnuRadio to process the full available spectrum but that's a balance you're going to have to find yourself.

--David
KI6ZHD

[Larry Dighera]

Hello Adrian,

Thank you for the gnuradio information. I'm happy to hear I won't need to
build a later version.

I spent several hours experimenting with pulseaudio daemon.conf parameters
after discovering the manual page. Apparently the CPU overhead of resampling
can be overcome by setting the pulseaudio sample rate the same as the source.
As gqrx has a fixed audio sample rate of 48K, I "default-sample-rate = 48000",
and set "resample-method = trivial" as the man page indicated this is best for
low CPU overhead. The upshot of my experimenting with pulseaudio daemon
parameters resulted in a very slight increase in audio signal intelligibility.
I don't think further pounding on pulseaudio will result in overcoming the
audio issue.

With regard to "diving into the gqrx code," I'm not a C programmer, but have
successfully modified C source code in the distant past (mid '80s) to
successfully achieve my goals. (Things have progressed a significantly since
then.) I agree; modifying gqrx is probably my only hope of successfully
running gqrx on the RPi3. I did a search of the gqrx source code for "filter"
and generated the list below. Without imposing on your kindness too much more,
perhaps you might provide me with a clue of where to start. If this is too
painful, I completely understand.

I am grateful for all the support you have provided in my Quixotic quest to get
my Airspy/Spyverter operational on the RPi3.

Best regards,
Larry

PS:
You mentioned that you have gqrx running under Debian Jessie on your phone.
What phone is that? Is it a quad-core processor or octo-core?

On Sun, 17 Jul 2016 15:49:08 +0000, Adrian Musceac <kant...@gmail.com> wrote:

>Hi Larry,

>I see you already have gnuradio running with hardfp-orc optimizations, so compiling from source is unlikely to improve things. Also, 4000 as a sample.rate will just lead to upsampling in Pulseaudio since most cards can't handle anything below 8000.
>
>If you're comfortable diving into the code of Gqrx, you could go and tweak all the filters in the chain. This will have a dramatic effect since a sharper filter with more taps will take a lot more iterations and CPU cycles.
>
>cheers,
>Adrian

=======================================================================
>./receivers/nbrx.cpp: filter = make_rx_filter(PREF_QUAD_RATE, -5000.0, 5000.0, 1000.0);
>./receivers/nbrx.cpp: connect(nb, 0, filter, 0);
>./receivers/nbrx.cpp: connect(filter, 0, meter, 0);
>./receivers/nbrx.cpp: connect(filter, 0, sql, 0);
>./receivers/nbrx.cpp:void nbrx::set_filter(double low, double high, double tw)
>./receivers/nbrx.cpp: filter->set_param(low, high, tw);
>./receivers/nbrx.cpp: filter->set_cw_offset(offset);
>./receivers/nbrx.h:#include "dsp/rx_filter.h"
>./receivers/nbrx.h: void set_filter(double low, double high, double tw);
>./receivers/nbrx.h: rx_filter_sptr filter; /*!< Non-translating bandpass filter.*/
>./receivers/wfmrx.h:#include "dsp/rx_filter.h"
>./receivers/wfmrx.h: void set_filter(double low, double high, double tw);
>./receivers/wfmrx.h: rx_filter_sptr filter; /*!< Non-translating bandpass filter.*/
>./receivers/wfmrx.cpp: filter = make_rx_filter(PREF_QUAD_RATE, -80000.0, 80000.0, 20000.0);
>./receivers/wfmrx.cpp: connect(iq_resamp, 0, filter, 0);
>./receivers/wfmrx.cpp: connect(filter, 0, meter, 0);
>./receivers/wfmrx.cpp: connect(filter, 0, sql, 0);
>./receivers/wfmrx.cpp:void wfmrx::set_filter(double low, double high, double tw)
>./receivers/wfmrx.cpp: filter->set_param(low, high, tw);
>./receivers/receiver_base.h: virtual void set_filter(double low, double high, double tw) = 0;
>./applications/gqrx/remote_control.h: qint64 rc_filter_offset;
>./applications/gqrx/mainwindow.cpp: d_filter_shape = receiver::FILTER_SHAPE_NORMAL;
>./applications/gqrx/mainwindow.cpp: connect(uiDockRxOpt, SIGNAL(filterOffsetChanged(qint64)), this, SLOT(setFilterOffset(qint64)));
>./applications/gqrx/mainwindow.cpp: connect(uiDockRxOpt, SIGNAL(filterOffsetChanged(qint64)), remote, SLOT(setFilterOffset(qint64)));
>./applications/gqrx/mainwindow.cpp: qint64 hw_freq = int64_val - d_lnb_lo - (qint64)(rx->get_filter_offset());
>./applications/gqrx/mainwindow.cpp: (qint64)(rx->get_filter_offset()) + d_lnb_lo;
>./applications/gqrx/mainwindow.cpp: * frequency range, the selected filter offset and the LNB LO.
>./applications/gqrx/mainwindow.cpp: * This function must therefore be called whenever the LNB LO or the filter
>./applications/gqrx/mainwindow.cpp: qint64 start = (qint64)(rx->get_filter_offset()) + d_hw_freq_start + d_lnb_lo;
>./applications/gqrx/mainwindow.cpp: qint64 stop = (qint64)(rx->get_filter_offset()) + d_hw_freq_stop + d_lnb_lo;
>./applications/gqrx/mainwindow.cpp: double hw_freq = (double)(rx_freq-d_lnb_lo) - rx->get_filter_offset();
>./applications/gqrx/mainwindow.cpp: qint64 center_freq = rx_freq - (qint64)rx->get_filter_offset();
>./applications/gqrx/mainwindow.cpp: * @brief Set new channel filter offset.
>./applications/gqrx/mainwindow.cpp: * @param freq_hz The new filter offset in Hz.
>./applications/gqrx/mainwindow.cpp: rx->set_filter_offset((double) freq_hz);
>./applications/gqrx/mainwindow.cpp: qint64 filter_offset = (qint64)rx->get_filter_offset();
>./applications/gqrx/mainwindow.cpp: ui->freqCtrl->setFrequency(d_lnb_lo + freq + filter_offset);
>./applications/gqrx/mainwindow.cpp: * and configures the default channel filter.
>./applications/gqrx/mainwindow.cpp: int filter_preset = uiDockRxOpt->currentFilter();
>./applications/gqrx/mainwindow.cpp: uiDockRxOpt->getFilterPreset(mode_idx, filter_preset, &flo, &fhi);
>./applications/gqrx/mainwindow.cpp: d_filter_shape = (receiver::filter_shape)uiDockRxOpt->currentFilterShape();
>./applications/gqrx/mainwindow.cpp: rx->set_filter((double)flo, (double)fhi, d_filter_shape);
>./applications/gqrx/mainwindow.cpp: /* update filter */
>./applications/gqrx/mainwindow.cpp: rx->set_filter(-5000.0, 5000.0, d_filter_shape);
>./applications/gqrx/mainwindow.cpp: rx->set_filter(-35000.0, 35000.0, d_filter_shape);
>./applications/gqrx/mainwindow.cpp: // set RX filter
>./applications/gqrx/mainwindow.cpp: rx->set_filter_offset((double) delta);
>./applications/gqrx/mainwindow.cpp: // update RF freq label and channel filter offset
>./applications/gqrx/mainwindow.cpp:/* CPlotter::NewfilterFreq() is emitted */
>./applications/gqrx/mainwindow.cpp: retcode = rx->set_filter((double) low, (double) high, d_filter_shape);
>./applications/gqrx/receiver.cpp: d_filter_offset(0.0),
>./applications/gqrx/receiver.cpp: * @brief Set filter offset.
>./applications/gqrx/receiver.cpp: * @param offset_hz The desired filter offset in Hz.
>./applications/gqrx/receiver.cpp: * @sa get_filter_offset()
>./applications/gqrx/receiver.cpp:receiver::status receiver::set_filter_offset(double offset_hz)
>./applications/gqrx/receiver.cpp: d_filter_offset = offset_hz;
>./applications/gqrx/receiver.cpp: lo->set_frequency(-d_filter_offset + d_cw_offset);
>./applications/gqrx/receiver.cpp: * @brief Get filter offset.
>./applications/gqrx/receiver.cpp: * @return The current filter offset.
>./applications/gqrx/receiver.cpp: * @sa set_filter_offset()
>./applications/gqrx/receiver.cpp:double receiver::get_filter_offset(void) const
>./applications/gqrx/receiver.cpp: return d_filter_offset;
>./applications/gqrx/receiver.cpp: lo->set_frequency(-d_filter_offset + d_cw_offset);
>./applications/gqrx/receiver.cpp:receiver::status receiver::set_filter(double low, double high, filter_shape shape)
>./applications/gqrx/receiver.cpp: rx->set_filter(low, high, trans_width);
>./applications/gqrx/receiver.cpp: * is located after the band pass filter. The full scale is 1.0
>./applications/gqrx/remote_control.cpp: rc_filter_offset = 0;
>./applications/gqrx/remote_control.cpp: rc_filter_offset = settings->value("receiver/offset", 0).toInt(&conv_ok);
>./applications/gqrx/remote_control.cpp: // Mode and filter
>./applications/gqrx/remote_control.cpp: * hardware frequency + the filter offset.
>./applications/gqrx/remote_control.cpp:/*! \brief Slot called when the filter offset is changed. */
>./applications/gqrx/remote_control.cpp: rc_filter_offset = freq;
>./applications/gqrx/remote_control.cpp: if (std::abs(rc_filter_offset + delta) < bw_half)
>./applications/gqrx/remote_control.cpp: // move filter offset
>./applications/gqrx/remote_control.cpp: rc_filter_offset += delta;
>./applications/gqrx/remote_control.cpp: emit newFilterOffset(rc_filter_offset);
>./applications/gqrx/remote_control.cpp: // reset the filter_offset, otherwise the MainWindo will preserve it
>./applications/gqrx/remote_control.cpp: rc_filter_offset = 0;
>./applications/gqrx/remote_control.cpp: emit newFilterOffset(rc_filter_offset);
>./applications/gqrx/mainwindow.h: enum receiver::filter_shape d_filter_shape;
>./applications/gqrx/mainwindow.h: void on_plotter_newDemodFreq(qint64 freq, qint64 delta); /*! New demod freq (aka. filter offset). */
>./applications/gqrx/mainwindow.h: void on_plotter_newFilterFreq(int low, int high); /*! New filter width */
>./applications/gqrx/receiver.h:#include "dsp/rx_filter.h"
>./applications/gqrx/receiver.h: enum filter_shape {
>./applications/gqrx/receiver.h: status set_filter_offset(double offset_hz);
>./applications/gqrx/receiver.h: double get_filter_offset(void) const;
>./applications/gqrx/receiver.h: status set_filter(double low, double high, filter_shape shape);
>./applications/gqrx/receiver.h: double d_filter_offset; /*!< Current filter offset */
>./qtgui/dockrxopt.cpp:static const int filter_preset_table[DockRxOpt::MODE_LAST][3][2] =
>./qtgui/dockrxopt.cpp:DockRxOpt::DockRxOpt(qint64 filterOffsetRange, QWidget *parent) :
>./qtgui/dockrxopt.cpp: ui->filterFreq->setup(7, -filterOffsetRange/2, filterOffsetRange/2, 1, UNITS_KHZ);
>./qtgui/dockrxopt.cpp: ui->filterFreq->setFrequency(0);
>./qtgui/dockrxopt.cpp: // use same slot for filteCombo and filterShapeCombo
>./qtgui/dockrxopt.cpp: connect(ui->filterShapeCombo, SIGNAL(activated(int)), this, SLOT(on_filterCombo_activated(int)));
>./qtgui/dockrxopt.cpp: * @brief Set value of channel filter offset selector.
>./qtgui/dockrxopt.cpp: ui->filterFreq->setFrequency(freq_hz);
>./qtgui/dockrxopt.cpp: * @brief Set filter offset range.
>./qtgui/dockrxopt.cpp: ui->filterFreq->setup(7, -range_hz/2, range_hz/2, 1, UNITS_KHZ);
>./qtgui/dockrxopt.cpp: * The actual RX frequency is the sum of the RF frequency and the filter
>./qtgui/dockrxopt.cpp: * Get filter index from filter LO / HI values.
>./qtgui/dockrxopt.cpp: * @param lo The filter low cut frequency.
>./qtgui/dockrxopt.cpp: * @param hi The filter high cut frequency.
>./qtgui/dockrxopt.cpp: * Given filter low and high cut frequencies, this function checks whether the
>./qtgui/dockrxopt.cpp: * filter settings correspond to one of the presets in filter_preset_table and
>./qtgui/dockrxopt.cpp: * returns the corresponding index to ui->filterCombo;
>./qtgui/dockrxopt.cpp:unsigned int DockRxOpt::filterIdxFromLoHi(int lo, int hi) const
>./qtgui/dockrxopt.cpp: if (lo == filter_preset_table[mode_index][FILTER_PRESET_WIDE][0] &&
>./qtgui/dockrxopt.cpp: hi == filter_preset_table[mode_index][FILTER_PRESET_WIDE][1])
>./qtgui/dockrxopt.cpp: else if (lo == filter_preset_table[mode_index][FILTER_PRESET_NORMAL][0] &&
>./qtgui/dockrxopt.cpp: hi == filter_preset_table[mode_index][FILTER_PRESET_NORMAL][1])
>./qtgui/dockrxopt.cpp: else if (lo == filter_preset_table[mode_index][FILTER_PRESET_NARROW][0] &&
>./qtgui/dockrxopt.cpp: hi == filter_preset_table[mode_index][FILTER_PRESET_NARROW][1])
>./qtgui/dockrxopt.cpp: * @brief Set filter parameters
>./qtgui/dockrxopt.cpp: int filter_index = filterIdxFromLoHi(lo, hi);
>./qtgui/dockrxopt.cpp: ui->filterCombo->setCurrentIndex(filter_index);
>./qtgui/dockrxopt.cpp: if (filter_index == FILTER_PRESET_USER)
>./qtgui/dockrxopt.cpp: ui->filterCombo->setItemText(FILTER_PRESET_USER, QString("User (%1 k)")
>./qtgui/dockrxopt.cpp: * @brief Select new filter preset.
>./qtgui/dockrxopt.cpp: * @param index Index of the new filter preset (0=wide, 1=normal, 2=narrow).
>./qtgui/dockrxopt.cpp: ui->filterCombo->setCurrentIndex(index);
>./qtgui/dockrxopt.cpp: * @brief Get current filter preset.
>./qtgui/dockrxopt.cpp: * @param The current filter preset (0=wide, 1=normal, 2=narrow).
>./qtgui/dockrxopt.cpp: return ui->filterCombo->currentIndex();
>./qtgui/dockrxopt.cpp:/** Select filter shape */
>./qtgui/dockrxopt.cpp: ui->filterShapeCombo->setCurrentIndex(index);
>./qtgui/dockrxopt.cpp: return ui->filterShapeCombo->currentIndex();
>./qtgui/dockrxopt.cpp:/** Get filter lo/hi for a given mode and preset */
>./qtgui/dockrxopt.cpp: *lo = filter_preset_table[mode][preset][0];
>./qtgui/dockrxopt.cpp: *hi = filter_preset_table[mode][preset][1];
>./qtgui/dockrxopt.cpp: emit filterOffsetChanged(offs);
>./qtgui/dockrxopt.cpp: qint64 offs = ui->filterFreq->getFrequency();
>./qtgui/dockrxopt.cpp: * @brief Channel filter offset has changed
>./qtgui/dockrxopt.cpp: * @param freq The new filter offset in Hz
>./qtgui/dockrxopt.cpp: * This slot is activated when a new filter offset has been selected either
>./qtgui/dockrxopt.cpp:void DockRxOpt::on_filterFreq_newFrequency(qint64 freq)
>./qtgui/dockrxopt.cpp: qDebug() << "New filter offset:" << freq << "Hz";
>./qtgui/dockrxopt.cpp: emit filterOffsetChanged(freq);
>./qtgui/dockrxopt.cpp: * New filter preset selected.
>./qtgui/dockrxopt.cpp: * demodulator and filter preset are tightly coupled.
>./qtgui/dockrxopt.cpp:void DockRxOpt::on_filterCombo_activated(int index)
>./qtgui/dockrxopt.cpp: qDebug() << "New filter preset:" << ui->filterCombo->currentText();
>./qtgui/dockrxopt.cpp: qDebug() << " shape:" << ui->filterShapeCombo->currentIndex();
>./qtgui/plotter.h: /*! \brief Move the filter to freq_hz from center. */
>./qtgui/plotter.h: bool m_FilterBoxEnabled; /*!< Draw filter box. */
>./qtgui/dockfft.h: void fftAvgChanged(float gain); /*! FFT video filter gain has changed. */
>./qtgui/dockrxopt.h: MODE_CWL = 8, /*!< CW using LSB filter. */
>./qtgui/dockrxopt.h: MODE_CWU = 9, /*!< CW using USB filter. */
>./qtgui/dockrxopt.h: explicit DockRxOpt(qint64 filterOffsetRange = 90000, QWidget *parent = 0);
>./qtgui/dockrxopt.h: unsigned int filterIdxFromLoHi(int lo, int hi) const;
>./qtgui/dockrxopt.h: /** Signal emitted when the channel filter frequency has changed. */
>./qtgui/dockrxopt.h: void filterOffsetChanged(qint64 freq_hz);
>./qtgui/dockrxopt.h: void on_filterFreq_newFrequency(qint64 freq);
>./qtgui/dockrxopt.h: void on_filterCombo_activated(int index);
>./qtgui/dockrxopt.ui: <widget class="CFreqCtrl" name="filterFreq">
>./qtgui/dockrxopt.ui: <string>&lt;html&gt;&lt;head/&gt;&lt;body&gt;&lt;p&gt;Channel filter offset.&lt;br/&gt;
>./qtgui/dockrxopt.ui: <widget class="QLabel" name="filterLabel">
>./qtgui/dockrxopt.ui: <widget class="QComboBox" name="filterCombo">
>./qtgui/dockrxopt.ui: <string>Apply mode dependent filter preset</string>
>./qtgui/dockrxopt.ui: <widget class="QLabel" name="filterShapeLabel">
>./qtgui/dockrxopt.ui: <widget class="QComboBox" name="filterShapeCombo">
>./qtgui/dockrxopt.ui: <string>Select the filter shape</string>
>./qtgui/plotter.cpp: "Drag filter edges to adjust filter."
>./qtgui/plotter.cpp:// filter edges.
>./qtgui/plotter.cpp: { // filter low cut
>./qtgui/plotter.cpp: { // filter high cut
>./qtgui/plotter.cpp: // filter width
>./qtgui/plotter.cpp: // filter shift
>./qtgui/plotter.cpp: // Draw demod filter box
>./qtgui/dockfft.cpp:/** FFT filter gain changed. */
>./qtgui/demod_options.ui: <string>Time constant for the FM de-emphasis IIR filter.
>./dsp/rx_fft.h:#include <gnuradio/filter/firdes.h> /* contains enum win_type */
>./dsp/rx_fft.h: * \param winttype The window type (see gnuradio/filter/firdes.h)
>./dsp/rx_fft.h:rx_fft_c_sptr make_rx_fft_c(unsigned int fftsize=4096, int wintype=gr::filter::firdes::WIN_HAMMING);
>./dsp/rx_fft.h: rx_fft_c(unsigned int fftsize=4096, int wintype=gr::filter::firdes::WIN_HAMMING);
>./dsp/rx_fft.h: * \param winttype The window type (see gnuradio/filter/firdes.h)
>./dsp/rx_fft.h:rx_fft_f_sptr make_rx_fft_f(unsigned int fftsize=1024, int wintype=gr::filter::firdes::WIN_HAMMING);
>./dsp/rx_fft.h: rx_fft_f(unsigned int fftsize=1024, int wintype=gr::filter::firdes::WIN_HAMMING);
>./dsp/hbf_decim.h:#include "filter/decimator.h"
>./dsp/hbf_decim.h: * Decimator block using half-band filters.
>./dsp/stereo_demod.h:#include <gnuradio/filter/firdes.h>
>./dsp/stereo_demod.h:#include <gnuradio/filter/fir_filter_fcc.h>
>./dsp/stereo_demod.h:#include <gnuradio/filter/fir_filter_fff.h>
>./dsp/stereo_demod.h: gr::filter::fir_filter_fcc::sptr tone; /*!< Pilot tone BPF. */
>./dsp/stereo_demod.h: gr::filter::fir_filter_fff::sptr lo2; /*!< Subtone BPF. */
>./dsp/stereo_demod.h: lpf_ff_sptr lpf0; /*!< Low-pass filter #0. */
>./dsp/stereo_demod.h: lpf_ff_sptr lpf1; /*!< Low-pass filter #1. */
>./dsp/rx_demod_fm.h:#include <gnuradio/filter/iir_filter_ffd.h>
>./dsp/rx_demod_fm.h:#include <gnuradio/filter/pfb_arb_resampler_ccf.h>
>./dsp/rx_demod_fm.h: gr::filter::iir_filter_ffd::sptr d_deemph; /*! De-emphasis IIR filter. */
>./dsp/rx_demod_fm.h: gr::filter::pfb_arb_resampler_ccf::sptr d_resampler; /*! PFB resampler. */
>./dsp/rx_demod_fm.h: /* De-emph IIR filter taps */
>./dsp/resampler_xx.cpp:#include <gnuradio/filter/firdes.h>
>./dsp/resampler_xx.cpp: d_taps = gr::filter::firdes::low_pass(flt_size, flt_size, cutoff, trans_width);
>./dsp/resampler_xx.cpp: /* create the filter */
>./dsp/resampler_xx.cpp: d_filter = gr::filter::pfb_arb_resampler_ccf::make(rate, d_taps, flt_size);
>./dsp/resampler_xx.cpp: /* connect filter */
>./dsp/resampler_xx.cpp: connect(self(), 0, d_filter, 0);
>./dsp/resampler_xx.cpp: connect(d_filter, 0, self(), 0);
>./dsp/resampler_xx.cpp: d_taps = gr::filter::firdes::low_pass(flt_size, flt_size, cutoff, trans_width);
>./dsp/resampler_xx.cpp: disconnect(self(), 0, d_filter, 0);
>./dsp/resampler_xx.cpp: disconnect(d_filter, 0, self(), 0);
>./dsp/resampler_xx.cpp: d_filter.reset();
>./dsp/resampler_xx.cpp: d_filter = gr::filter::pfb_arb_resampler_ccf::make(rate, d_taps, flt_size);
>./dsp/resampler_xx.cpp: connect(self(), 0, d_filter, 0);
>./dsp/resampler_xx.cpp: connect(d_filter, 0, self(), 0);
>./dsp/resampler_xx.cpp: d_taps = gr::filter::firdes::low_pass(flt_size, flt_size, cutoff, trans_width);
>./dsp/resampler_xx.cpp: /* create the filter */
>./dsp/resampler_xx.cpp: d_filter = gr::filter::pfb_arb_resampler_fff::make(rate, d_taps, flt_size);
>./dsp/resampler_xx.cpp: /* connect filter */
>./dsp/resampler_xx.cpp: connect(self(), 0, d_filter, 0);
>./dsp/resampler_xx.cpp: connect(d_filter, 0, self(), 0);
>./dsp/resampler_xx.cpp: d_taps = gr::filter::firdes::low_pass(flt_size, flt_size, cutoff, trans_width);
>./dsp/resampler_xx.cpp: disconnect(self(), 0, d_filter, 0);
>./dsp/resampler_xx.cpp: disconnect(d_filter, 0, self(), 0);
>./dsp/resampler_xx.cpp: d_filter.reset();
>./dsp/resampler_xx.cpp: d_filter = gr::filter::pfb_arb_resampler_fff::make(rate, d_taps, flt_size);
>./dsp/resampler_xx.cpp: connect(self(), 0, d_filter, 0);
>./dsp/resampler_xx.cpp: connect(d_filter, 0, self(), 0);
>./dsp/rx_filter.h:#include <gnuradio/filter/fir_filter_ccc.h>
>./dsp/rx_filter.h:#include <gnuradio/filter/freq_xlating_fir_filter_ccc.h>
>./dsp/rx_filter.h:#define RX_FILTER_MIN_WIDTH 100 /*! Minimum width of filter */
>./dsp/rx_filter.h:class rx_filter;
>./dsp/rx_filter.h:class rx_xlating_filter;
>./dsp/rx_filter.h:typedef boost::shared_ptr<rx_filter> rx_filter_sptr;
>./dsp/rx_filter.h:typedef boost::shared_ptr<rx_xlating_filter> rx_xlating_filter_sptr;
>./dsp/rx_filter.h:/*! \brief Return a shared_ptr to a new instance of rx_filter.
>./dsp/rx_filter.h: * \param low The lower limit of the bandpass filter.
>./dsp/rx_filter.h: * \param high The upper limit of the filter.
>./dsp/rx_filter.h: * of raw pointers, rx_filter's constructor is private.
>./dsp/rx_filter.h: * make_rxfilter is the public interface for creating new instances.
>./dsp/rx_filter.h:rx_filter_sptr make_rx_filter(double sample_rate,
>./dsp/rx_filter.h:/*! \brief Complex band-pass filter with complex taps.
>./dsp/rx_filter.h: * This class encapsulates a complex FIR filter and the code
>./dsp/rx_filter.h: * required to generate complex band pass filter taps. It provides a simple
>./dsp/rx_filter.h: * interface to set the filter parameters.
>./dsp/rx_filter.h: * performed by the accessors (though the taps generator from gr::filter::firdes does perform
>./dsp/rx_filter.h:class rx_filter : public gr::hier_block2
>./dsp/rx_filter.h: rx_filter(double sample_rate=96000.0, double low=-5000.0, double high=5000.0, double trans_width=1000.0); // FIXME: should be private
>./dsp/rx_filter.h: ~rx_filter();
>./dsp/rx_filter.h: gr::filter::fir_filter_ccc::sptr d_bpf;
>./dsp/rx_filter.h:/*! \brief Return a shared_ptr to a new instance of rx_xlating_filter.
>./dsp/rx_filter.h: * \param offset The filter offset.
>./dsp/rx_filter.h: * \param low The lower limit of the bandpass filter.
>./dsp/rx_filter.h: * \param high The upper limit of the filter.
>./dsp/rx_filter.h: * of raw pointers, rx_filter's constructor is private.
>./dsp/rx_filter.h: * make_rxfilter is the public interface for creating new instances.
>./dsp/rx_filter.h:rx_xlating_filter_sptr make_rx_xlating_filter(double sample_rate,
>./dsp/rx_filter.h:/*! \brief Frequency translating band-pass filter with complex taps.
>./dsp/rx_filter.h: * This class encapsulates a frequency translating FIR filter and the code
>./dsp/rx_filter.h: * required to generate complex band pass filter taps. It provides a simple
>./dsp/rx_filter.h: * interface to set the filter offset and limits and takes care of generating
>./dsp/rx_filter.h: * The filter limits are relative to the filter offset and thanks to the complex taps
>./dsp/rx_filter.h: * performed by the accessors (though the taps generator from gr::filter::firdes does perform
>./dsp/rx_filter.h:class rx_xlating_filter : public gr::hier_block2
>./dsp/rx_filter.h: rx_xlating_filter(double sample_rate=96000.0, double center=0.0, double low=-5000.0, double high=5000.0, double trans_width=1000.0); // FIXME: should be private
>./dsp/rx_filter.h: ~rx_xlating_filter();
>./dsp/rx_filter.h: gr::filter::freq_xlating_fir_filter_ccc::sptr d_bpf;
>./dsp/rx_rds.cpp:#include <gnuradio/filter/firdes.h>
>./dsp/rx_rds.cpp: d_taps2 = gr::filter::firdes::low_pass(2500.0, d_sample_rate, 2400, 2000);
>./dsp/rx_rds.cpp: f_fxff = gr::filter::freq_xlating_fir_filter_fcf::make(5.0, d_taps2, 57000, d_sample_rate);
>./dsp/rx_rds.cpp: f_rrcf = gr::filter::firdes::root_raised_cosine(1, sample_rate/5, 2375, 1, 100);
>./dsp/rx_rds.cpp: d_bpf2 = gr::filter::fir_filter_ccf::make(1, f_rrcf);
>./dsp/rx_rds.cpp: /* connect filter */
>./dsp/rx_demod_am.h:#include <gnuradio/filter/iir_filter_ffd.h>
>./dsp/rx_demod_am.h: * This block implements an optional IIR DC-removal filter for the demodulated signal.
>./dsp/rx_demod_am.h: gr::filter::iir_filter_ffd::sptr d_dcr; /*! DC removal (IIR high pass). */
>./dsp/rx_demod_am.h: /* IIR DC-removal filter taps */
>./dsp/CMakeLists.txt: afsk1200/filter-i386.h
>./dsp/CMakeLists.txt: afsk1200/filter.h
>./dsp/CMakeLists.txt: filter/decimator.cpp
>./dsp/CMakeLists.txt: filter/decimator.h
>./dsp/CMakeLists.txt: filter/filtercoef_hbf_70.h
>./dsp/CMakeLists.txt: filter/filtercoef_hbf_100.h
>./dsp/CMakeLists.txt: filter/filtercoef_hbf_140.h
>./dsp/CMakeLists.txt: rx_filter.cpp
>./dsp/CMakeLists.txt: rx_filter.h
>./dsp/lpf.h:#include <gnuradio/filter/firdes.h>
>./dsp/lpf.h:#include <gnuradio/filter/fir_filter_fff.h>
>./dsp/lpf.h: * \param gain Overall gain of filter (typically 1.0).
>./dsp/lpf.h:/*! \brief low-pass filter (LPF) with float taps.
>./dsp/lpf.h: * This class encapsulates a low-pass FIR filter and the code
>./dsp/lpf.h: * required to generate filter taps. It provides a simple
>./dsp/lpf.h: * interface to set the filter parameters.
>./dsp/lpf.h: * performed by the accessors (though the taps generator from gr::filter::firdes does perform
>./dsp/lpf.h: gr::filter::fir_filter_fff::sptr lpf;
>./dsp/lpf.cpp:#include <gnuradio/filter/firdes.h>
>./dsp/lpf.cpp: d_taps = gr::filter::firdes::low_pass(d_gain, d_sample_rate,
>./dsp/lpf.cpp: /* create low-pass filter (decimation=1) */
>./dsp/lpf.cpp: lpf = gr::filter::fir_filter_fff::make(1, d_taps);
>./dsp/lpf.cpp: /* connect filter */
>./dsp/lpf.cpp: d_taps = gr::filter::firdes::low_pass(d_gain, d_sample_rate,
>./dsp/correct_iq_cc.h:#include <gnuradio/filter/single_pole_iir_filter_cc.h>
>./dsp/correct_iq_cc.h: * \param tau The time constant for the filter
>./dsp/correct_iq_cc.h:/*! \brief Single pole IIR filter-based DC offset correction block.
>./dsp/correct_iq_cc.h: * filter
>./dsp/correct_iq_cc.h: gr::filter::single_pole_iir_filter_cc::sptr d_iir;
>./dsp/rx_fft.cpp:#include <gnuradio/filter/firdes.h>
>./dsp/rx_fft.cpp: * \param wintype The window type (see gr::filter::firdes::win_type).
>./dsp/rx_fft.cpp: if ((d_wintype < gr::filter::firdes::WIN_HAMMING) || (d_wintype > gr::filter::firdes::WIN_BLACKMAN_hARRIS))
>./dsp/rx_fft.cpp: d_wintype = gr::filter::firdes::WIN_HAMMING;
>./dsp/rx_fft.cpp: d_window = gr::filter::firdes::window((gr::filter::firdes::win_type)d_wintype, d_fftsize, 6.76);
>./dsp/rx_fft.cpp: * \param wintype The window type (see gr::filter::firdes::win_type).
>./dsp/rx_fft.cpp: if ((d_wintype < gr::filter::firdes::WIN_HAMMING) || (d_wintype > gr::filter::firdes::WIN_BLACKMAN_hARRIS))
>./dsp/rx_fft.cpp: d_wintype = gr::filter::firdes::WIN_HAMMING;
>./dsp/rx_fft.cpp: d_window = gr::filter::firdes::window((gr::filter::firdes::win_type)d_wintype, d_fftsize, 6.76);
>./dsp/rx_noise_blanker_cc.h: * This block implements noise blanking filters based on the noise blanker code
>./dsp/resampler_xx.h:#include <gnuradio/filter/pfb_arb_resampler_ccf.h>
>./dsp/resampler_xx.h:#include <gnuradio/filter/pfb_arb_resampler_fff.h>
>./dsp/resampler_xx.h: * of generating filter taps that can be used for the filter, as well as calculating
>./dsp/resampler_xx.h: gr::filter::pfb_arb_resampler_ccf::sptr d_filter;
>./dsp/resampler_xx.h: * of generating filter taps that can be used for the filter, as well as calculating
>./dsp/resampler_xx.h: gr::filter::pfb_arb_resampler_fff::sptr d_filter;
>./dsp/filter/filtercoef_hbf_100.h: * Half-band filter coefficients with 100 dB stop band attenuation.
>./dsp/filter/decimator.h: * Decimate by power-of-2 classes using half band filters.
>./dsp/filter/decimator.h: * 11-tap half-band filter with unrolled loop.
>./dsp/filter/decimator.h: int init_filters_70(unsigned int decimation);
>./dsp/filter/decimator.h: int init_filters_100(unsigned int decimation);
>./dsp/filter/decimator.h: int init_filters_140(unsigned int decimation);
>./dsp/filter/decimator.h: void delete_filters();
>./dsp/filter/decimator.h: CDec2 *filter_table[MAX_STAGES];
>./dsp/filter/filtercoef_hbf_140.h: * Half-band filter coefficients with 140 dB stop band attenuation.
>./dsp/filter/filtercoef_hbf_140.h:// normalized 140 dB alias free bandwidths for the filters
>./dsp/filter/filtercoef_hbf_70.h: * Half-band filter coefficients with 70 dB stop band attenuation.
>./dsp/filter/decimator.cpp: * Decimate by power-of-2 using half band filters.
>./dsp/filter/decimator.cpp:#include "filtercoef_hbf_70.h"
>./dsp/filter/decimator.cpp:#include "filtercoef_hbf_100.h"
>./dsp/filter/decimator.cpp:#include "filtercoef_hbf_140.h"
>./dsp/filter/decimator.cpp: filter_table[i] = 0;
>./dsp/filter/decimator.cpp: delete_filters();
>./dsp/filter/decimator.cpp: delete_filters();
>./dsp/filter/decimator.cpp: decim = init_filters_70(_decim);
>./dsp/filter/decimator.cpp: decim = init_filters_100(_decim);
>./dsp/filter/decimator.cpp: decim = init_filters_140(_decim);
>./dsp/filter/decimator.cpp: while (filter_table[i])
>./dsp/filter/decimator.cpp: n = filter_table[i++]->DecBy2(n, pin, pin);
>./dsp/filter/decimator.cpp:void Decimator::delete_filters()
>./dsp/filter/decimator.cpp: if (filter_table[i])
>./dsp/filter/decimator.cpp: delete filter_table[i];
>./dsp/filter/decimator.cpp: filter_table[i] = 0;
>./dsp/filter/decimator.cpp:int Decimator::init_filters_70(unsigned int decimation)
>./dsp/filter/decimator.cpp: filter_table[n++] = new CHalfBand11TapDecimateBy2(HBF_70_11);
>./dsp/filter/decimator.cpp: filter_table[n++] = new CHalfBandDecimateBy2(HBF_70_39_LENGTH, HBF_70_39);
>./dsp/filter/decimator.cpp:int Decimator::init_filters_100(unsigned int decimation)
>./dsp/filter/decimator.cpp: filter_table[n++] = new CHalfBand11TapDecimateBy2(HBF_100_11);
>./dsp/filter/decimator.cpp: filter_table[n++] = new CHalfBandDecimateBy2(HBF_100_19_LENGTH, HBF_100_19);
>./dsp/filter/decimator.cpp: filter_table[n++] = new CHalfBandDecimateBy2(HBF_100_59_LENGTH, HBF_100_59);
>./dsp/filter/decimator.cpp:int Decimator::init_filters_140(unsigned int decimation)
>./dsp/filter/decimator.cpp: filter_table[n++] = new CHalfBand11TapDecimateBy2(HBF_140_11);
>./dsp/filter/decimator.cpp: filter_table[n++] = new CHalfBandDecimateBy2(HBF_140_15_LENGTH, HBF_140_15);
>./dsp/filter/decimator.cpp: filter_table[n++] = new CHalfBandDecimateBy2(HBF_140_27_LENGTH, HBF_140_27);
>./dsp/filter/decimator.cpp: filter_table[n++] = new CHalfBandDecimateBy2(HBF_140_87_LENGTH, HBF_140_87);
>./dsp/filter/decimator.cpp: * Half band filter and decimate by 2 function.
>./dsp/filter/decimator.cpp: // perform decimation FIR filter on even samples
>./dsp/filter/decimator.cpp: * Decimate by 2 Fixed 11 Tap Halfband filter class implementation
>./dsp/filter/decimator.cpp: * Decimate by 2 Fixed 11 Tap Halfband filter class implementation
>./dsp/resampler_ff_old.cpp: /* create band pass filter */
>./dsp/resampler_ff_old.cpp: /* connect filter */
>./dsp/correct_iq_cc.cpp: d_iir = gr::filter::single_pole_iir_filter_cc::make(d_alpha, 1);
>./dsp/afsk1200/filter-i386.h: * filter-i386.h -- optimized filter routines
>./dsp/afsk1200/cafsk12.cpp:#include "filter.h"
>./dsp/afsk1200/filter.h: * filter.h -- optimized filter routines
>./dsp/afsk1200/filter.h:#include "filter-i386.h"
>./dsp/rx_demod_am.cpp: d_dcr = gr::filter::iir_filter_ffd::make(d_fftaps, d_fbtaps);
>./dsp/rx_meter.h: * make_rxfilter is the public interface for creating new instances.
>./dsp/agc_impl.cpp://adjust to cover the impulse response time of filter
>./dsp/agc_impl.cpp: // calculate fast and slow filter values.
>./dsp/rx_rds.h:#include <gnuradio/filter/fir_filter_ccc.h>
>./dsp/rx_rds.h:#include <gnuradio/filter/fir_filter_ccf.h>
>./dsp/rx_rds.h:#include <gnuradio/filter/fir_filter_fff.h>
>./dsp/rx_rds.h:#include <gnuradio/filter/freq_xlating_fir_filter_fcf.h>
>./dsp/rx_rds.h:#include <gnuradio/filter/freq_xlating_fir_filter_ccc.h>
>./dsp/rx_rds.h:#include <gnuradio/filter/freq_xlating_fir_filter_ccf.h>
>./dsp/rx_rds.h: gr::filter::fir_filter_ccc::sptr d_bpf;
>./dsp/rx_rds.h: gr::filter::fir_filter_ccf::sptr d_bpf2;
>./dsp/rx_rds.h: gr::filter::freq_xlating_fir_filter_fcf::sptr f_fxff;
>./dsp/rx_rds.h: gr::filter::freq_xlating_fir_filter_ccf::sptr f_fxff_ccf;
>./dsp/rx_demod_fm.cpp:#include <gnuradio/filter/firdes.h>
>./dsp/rx_demod_fm.cpp: d_deemph = gr::filter::iir_filter_ffd::make(d_fftaps, d_fbtaps);
>./dsp/rx_demod_fm.cpp: * \bug Assumes that IIR filter has already been constructed so that we
>./dsp/rx_demod_fm.cpp:/*! \brief Calculate taps for FM de-emph IIR filter. */
>./dsp/hbf_decim.cpp:#include "filter/decimator.h"
>./dsp/resampler_ff_old.h: * of generating filter taps that can be used for the resampler, as well as calculating
>./dsp/rx_filter.cpp:#include <gnuradio/filter/firdes.h>
>./dsp/rx_filter.cpp:#include "dsp/rx_filter.h"
>./dsp/rx_filter.cpp: * Create a new instance of rx_filter and return
>./dsp/rx_filter.cpp:rx_filter_sptr make_rx_filter(double sample_rate, double low, double high, double trans_width)
>./dsp/rx_filter.cpp: return gnuradio::get_initial_sptr(new rx_filter(sample_rate, low, high, trans_width));
>./dsp/rx_filter.cpp:rx_filter::rx_filter(double sample_rate, double low, double high, double trans_width)
>./dsp/rx_filter.cpp: : gr::hier_block2 ("rx_filter",
>./dsp/rx_filter.cpp: d_taps = gr::filter::firdes::complex_band_pass(1.0, d_sample_rate, d_low, d_high, d_trans_width);
>./dsp/rx_filter.cpp: /* create band pass filter */
>./dsp/rx_filter.cpp: d_bpf = gr::filter::fir_filter_ccc::make(1, d_taps);
>./dsp/rx_filter.cpp: /* connect filter */
>./dsp/rx_filter.cpp:rx_filter::~rx_filter ()
>./dsp/rx_filter.cpp:void rx_filter::set_param(double low, double high, double trans_width)
>./dsp/rx_filter.cpp: d_taps = gr::filter::firdes::complex_band_pass(1.0, d_sample_rate,
>./dsp/rx_filter.cpp: std::cout << "Genrating taps for new filter LO:" << d_low
>./dsp/rx_filter.cpp:void rx_filter::set_cw_offset(double offset)
>./dsp/rx_filter.cpp:/** Frequency translating filter **/
>./dsp/rx_filter.cpp: * Create a new instance of rx_xlating_filter and return
>./dsp/rx_filter.cpp:rx_xlating_filter_sptr make_rx_xlating_filter(double sample_rate, double center, double low, double high, double trans_width)
>./dsp/rx_filter.cpp: return gnuradio::get_initial_sptr(new rx_xlating_filter(sample_rate, center, low, high, trans_width));
>./dsp/rx_filter.cpp:rx_xlating_filter::rx_xlating_filter(double sample_rate, double center, double low, double high, double trans_width)
>./dsp/rx_filter.cpp: : gr::hier_block2 ("rx_xlating_filter",
>./dsp/rx_filter.cpp: d_taps = gr::filter::firdes::complex_band_pass(1.0, d_sample_rate, -d_high, -d_low, d_trans_width);
>./dsp/rx_filter.cpp: /* create band pass filter */
>./dsp/rx_filter.cpp: d_bpf = gr::filter::freq_xlating_fir_filter_ccc::make(1, d_taps, d_center, d_sample_rate);
>./dsp/rx_filter.cpp: /* connect filter */
>./dsp/rx_filter.cpp:rx_xlating_filter::~rx_xlating_filter()
>./dsp/rx_filter.cpp:void rx_xlating_filter::set_offset(double center)
>./dsp/rx_filter.cpp:void rx_xlating_filter::set_param(double low, double high, double trans_width)
>./dsp/rx_filter.cpp: d_taps = gr::filter::firdes::complex_band_pass(1.0, d_sample_rate, -d_high, -d_low, d_trans_width);
>./dsp/rx_filter.cpp:void rx_xlating_filter::set_param(double center, double low, double high, double trans_width)
>./dsp/stereo_demod.cpp: d_tone_taps = gr::filter::firdes::complex_band_pass(
>./dsp/stereo_demod.cpp: d_tone_taps = gr::filter::firdes::complex_band_pass(
>./dsp/stereo_demod.cpp: tone = gr::filter::fir_filter_fcc::make(1, d_tone_taps);
>./dsp/stereo_demod.cpp: d_pll_taps = gr::filter::firdes::band_pass(
>./dsp/stereo_demod.cpp: lo2 = gr::filter::fir_filter_fff::make(1, d_pll_taps);
=======================================================================

[Larry Dighera]

Hello David,

Thanks for the kind words.

I'll put my comments in-line below too.

On Sun, 17 Jul 2016 10:10:54 -0700 (PDT), David Ranch <dra...@gmail.com> wrote:

>Hello Larry,
>
>Nice work on recompiling things and digging into the deep underworld that
>is PulseAudio! Few things struck me in this thread worth mentioning:
>
> 1. You need to get the gnuradio build failures fixed. I think the error
>you cited is actually just a warning and you needed to scroll up farther to
>find the real failure (Cmake building things in parallel really makes this
>harder than it should). I feel your pain here as compiling GnuRadio is a
>brutal process (takes forever) and really takes a computer to it's knees.
>I see you're running 3.7.5 though 3.7.9.2 is current.
>

Thank you for the clue. Adrian has indicated that gnuradio 3.7.5 has
hardfp-orc optimizations, so I'm thinking building gnuradio 3.7.9.2 may not be
necessary for enabling gqrx to run on the RPi3. Do you agree, or do you
believe gnuradio 3.7.9.2 will provide a performance improvement?

It would seem I am very close to success in building gnuradio on the RPi3 under
Debian Jessie. I have attached complete cmake and make output text files to
this message, and am e-mailing this message to you so the attachments don't
land in the bit bucket. Any insight you may be able to provide in overcoming
the single gnuradio build error will be greatly appreciated.

>
> 2. Have you run the Volk optimizations? In my doc (
>http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#42b3.gnuradio-installing)
>, I recommend to reboot your Rpi, log in as yourself, and run:
>--
> # takes 18min 22sec on a i5-2430M running 2.4Ghz w/ 4GB RAM - only uses
>a single core
> time volk_profile
>--
>

On the page at that link, I found this:

"It's now HIGHLY recommended to optimize your GnuRadio
software for your specific computer. From the command line run this
command while
NOT using your computer for anything:

#Do not run this as the root user

# takes 18min 22sec on a i5-2430M running 2.4Ghz w/ 4GB RAM - only uses
a single core

time volk_profile

This command will allow GnuRadio to best utilize your specific hardware.
This is a VERY time consuming process so let it complete. The output of
the command will write it's settings to $HOME/.volk/volk_config . If
multiple users are going to use GnuRadio / Gqrx / etc on this machine, they
will need to either copy this file in their home directory or run the
"volk_profile" themselves."

But, not before I had run 'time folk_profile' as user root (with CPU set to
1200 overclocked). I'm curious why the results might be different if run from
a non-superuser account? At any rate, here are the results:

#this file is generated by volk_profile.
#the function name is followed by the preferred architecture.
volk_16ic_deinterleave_real_8i u_orc u_orc
volk_16ic_deinterleave_16i_x2 u_orc u_orc
volk_16ic_s32f_deinterleave_32f_x2 generic generic
volk_16i_s32f_convert_32f generic generic
volk_16i_convert_8i a_generic generic
volk_16u_byteswap u_orc u_orc
volk_32f_x2_add_32f u_neon u_neon
volk_32fc_32f_multiply_32fc neon neon
volk_32fc_x2_conjugate_dot_prod_32fc a_generic generic
volk_32fc_deinterleave_64f_x2 a_generic generic
volk_32fc_x2_dot_prod_32fc neon_optfma neon_optfma
volk_32fc_32f_dot_prod_32fc a_neonpipeline neon_unroll
volk_32fc_s32f_magnitude_16i generic generic
volk_32fc_magnitude_32f neon neon
volk_32fc_magnitude_squared_32f neon neon
volk_32fc_x2_multiply_32fc generic generic
volk_32fc_x2_multiply_conjugate_32fc neon neon
volk_32fc_conjugate_32fc a_neon generic
volk_32f_s32f_convert_16i a_generic generic
volk_32f_s32f_convert_32i generic generic
volk_32f_convert_64f a_generic generic
volk_32f_s32f_convert_8i a_generic generic
volk_32fc_x2_square_dist_32f neon neon
volk_32f_x2_divide_32f u_orc u_orc
volk_32f_x2_dot_prod_32f neonasm neonasm
volk_32f_x2_interleave_32fc neon neon
volk_32f_x2_max_32f neon neon
volk_32f_x2_min_32f neon neon
volk_32f_x2_multiply_32f neon neon
volk_32f_s32f_normalize u_orc u_orc
volk_32f_sqrt_32f neon neon
volk_32f_x2_subtract_32f neon neon
volk_32f_x3_sum_of_poly_32f neonvert neonvert
volk_32i_x2_and_32i u_orc u_orc
volk_32i_s32f_convert_32f generic generic
volk_32i_x2_or_32i u_orc u_orc
volk_32u_byteswap a_generic generic
volk_64f_convert_32f a_generic generic
volk_64u_byteswap generic generic
volk_8ic_deinterleave_real_8i neon neon
volk_8i_convert_16i neon neon
volk_8i_s32f_convert_32f u_orc u_orc
volk_32fc_s32fc_multiply_32fc a_generic generic
volk_32f_s32f_multiply_32f u_neon u_neon
volk_32f_binary_slicer_32i generic generic
volk_32f_binary_slicer_8i generic_branchless generic_branchless

real 25m24.00s
user 25m23.00s
sys 0m2.63s

That's only 7 minutes and 2 seconds longer than it took on your I5 machine,

>
>That step will take a long time on an Rpi but will make sure GnuRadio
>optimizes as fast as possible
>
>
> 3. The Broadcom SOC chip *will* throttle itself if it gets hot and at
>that point, all bets are off for performance. How do you have your Rpi
>mounted (in a case, etc)? Is it in a case with good ventilation? Do you
>have 3rd party heat sinks on it that might have poor thermal pads? Is
>there a fan on it that's not turning? You might want to add a temp
>monitoring program to your Rpi to watch it -
>https://www.google.com/search?q=raspberry+pi+CPU+temp+monitoring
>

Yes. RPi3 overheating is an issue for any CPU intensive processes. I have the
chips heat sinked with a small fan blowing directly on them. Temperature
remains well below 70 degrees C, typically about 40 degrees C as reported by
both the X11 temperature monitor widget and the command line utility.

Thank you for pointing out the alsa-capabilities script page. I will explore
that, and post my findings.

I spent several hours experimenting with pulseaudio daemon.conf parameters
after discovering the manual page. Apparently the CPU overhead of resampling
can be overcome by setting the pulseaudio sample rate the same as the source.

As gqrx has a fixed audio sample rate of 48K, I set "default-sample-rate =

48000", and set "resample-method = trivial" as the man page indicated this is
best for low CPU overhead. The upshot of my experimenting with pulseaudio
daemon parameters resulted in a very slight increase in audio signal
intelligibility. I don't think further pounding on pulseaudio will result in
overcoming the audio issue.

Another subscriber to this group kindly suggested a possible method of reducing
gqrx CPU usage as a possible next step toward enabling gqrx to run on the RPi3:

"If you're comfortable diving into the code of Gqrx, you could go and tweak
all the filters in the chain. This will have a dramatic effect since a
sharper filter with more taps will take a lot more iterations and CPU
cycles."

Unfortunately I have no clue how to approach that. I have attached (and
included below) a third text file that contains the output of a 'find' command
that found all instances of the word 'filter' in the gqrx source code.

I am grateful for your extensive effort to assist me in getting gqrx to run on
the RPi3. If this can be successfully accomplished, I believe there will be
many other amateur radio operators who will also be in your debt. Thank you.

Best regards,
Larry


====================================================================================

==========================================================================

[Larry Dighera]

As promised, here is the output of the alsa-capabilities script:

# bash <(wget -q -O - "http://lacocina.nl/alsa-capabilities") -l a -s
0) Analog alsa audio output interface `hw:0,0'
- device name = bcm2835 ALSA
- interface name = bcm2835 ALSA
- usb audio class = (n/a)
- character device = /dev/snd/pcmC0D0p
- rates per format = U8: 32000Hz 44100Hz 48000Hz
S16_LE: 32000Hz 44100Hz 48000Hz
- monitor file = /proc/asound/card0/pcm0p/sub0/hw_params
- stream file = (n/a)

1) Analog alsa audio output interface `hw:0,1'
- device name = bcm2835 ALSA
- interface name = bcm2835 IEC958/HDMI
- usb audio class = (n/a)
- character device = /dev/snd/pcmC0D1p
- rates per format = S16_LE: 44100Hz 48000Hz
- monitor file = /proc/asound/card0/pcm1p/sub0/hw_params
- stream file = (n/a)

From the above data, it would appear that either audio device supports 48k
sampling.

I currently have the pulseaudio sample rate set the same as the gqrx (source)
audio sample rate: 48k. As gqrx has a fixed audio sample rate of 48K, I set
the pulseaudio daemon.conf "default-sample-rate = >48000", and set

"resample-method = trivial" as the man page indicated this is best for low CPU
overhead.

Audio still stutters and is unintelligible.

While the on-chip temperature sensor indicates <40 degrees C, occasionally I
see the rainbow square materialize momentarily in the upper right hand corner
of the X11 desktop display.

So, I'll write a little script to report CPU frequency and see if I can detect
any throttling.

At this point, I'm thinking the only way to get gqrx to run nominally on the
Raspberry Pi 3 is to investigate reducing the filter poles by editing the gqrx
source code. All clues how to approach this are welcome.

[Alexandru Csete]

On Thu, Jul 28, 2016 at 12:44 AM, Larry Dighera <LDig...@att.net> wrote:
>
> At this point, I'm thinking the only way to get gqrx to run nominally on the
> Raspberry Pi 3 is to investigate reducing the filter poles by editing the gqrx
> source code. All clues how to approach this are welcome.
>

Hi Larry,

Although I can help you with that, I am not convinced it will make the
necessary difference.

You can already reduce the number of requiored poles in the filter
from the GUI. First, select filter shape "soft", then make the filter
as wide as you can by dragging the edge. Clearly, you can not use a 20
kHz wide filter for SSB reception, but it can give you an indication
whether it may make a difference.

I went back to your original post and saw that you are using the
Airspy mini. Well, that's bad news because the high CPU load may come
already from the driver. The Airspy relies on the driver to convert
the samples to complex format and those conversions happen at full
sample rate.

You can test it using the "airspy_rx -r /dev/null -t 0" and see if it
can reach the required sample throughput. You can also check that no
single CPU core gets close to 100%.

Also, just to be sure, please check that you are using the correct
sample rate in gqrx. Gqrx can't see if it is an Airspy or an Airspy
mini, so you have to enter the correct sample rate manually in the I/O
config dialog.

Alex

[Larry Dighera]

Hello Alex,

First, let me say thank you for gqrx! I very much appreciate your hard work on
this project.

I realize that you have little interest in getting gqrx to run on the RPi3, and
have refrained from bothering you for that reason. So, I've very grateful for
your comments and pointers. Thank you for your support.

As you suggested, I will change the gqrx filter settings and see if there is
any change/improvement in the hope of determining if pursuing that route may be
worth the effort. I'll report my findings here as time permits.

Here are the results of the "airspy_rx -r /dev/null -t 0" test:

# airspy_rx -r /dev/null -t 0
Device Serial Number: 0x04A464C83618440B
Stop with Ctrl-C
Streaming at 5.861 MSPS
Streaming at 5.771 MSPS
Streaming at 5.709 MSPS
Streaming at 5.687 MSPS
Streaming at 5.644 MSPS
Streaming at 5.522 MSPS
Streaming at 5.440 MSPS
Streaming at 5.544 MSPS
Streaming at 5.569 MSPS
Streaming at 5.575 MSPS
Streaming at 5.583 MSPS
Streaming at 5.588 MSPS
Streaming at 5.590 MSPS
Streaming at 5.593 MSPS
Streaming at 5.596 MSPS
Streaming at 5.608 MSPS
Streaming at 5.614 MSPS
Streaming at 5.624 MSPS
Streaming at 5.631 MSPS
Streaming at 5.636 MSPS
Streaming at 5.636 MSPS
^CCaught signal 2

User cancel, exiting...
Total time: 21.3836 s
Average speed 5.6164 MSPS IQ
done
--------------

The sample rate appears to be below the required 6 MSPS rate.

So, I switched to the RTL-SDR dongle set to 1800 SPS and broadcast FM
reception. The audio from gqrx was slightly improved, in that it could be
coaxed to output continuous audio by setting the mode to UCW. Of course, the
FM audio was not intelligible with that mode, but it was continuous for the
first time.

Setting the filter shape and width did have some (negative) effect...

So, it would appear that we are making some limited progress. At this point,
the only things I can think of to try to get gqrx to play live audio on the
RPi3 are perhaps:

1. Recompile gnuradio, but the build process has an error (see previous
post)

2. Recompile gqrx. I don't know what this may accomplish.

3. Dive into the gqrx source, and see if the filtering can be modified to
require less CPU loading in the hope that that will enable good audio output.

Any suggestions, or tests that anyone may suggest will be welcome.

Thank you again, Alex, for your help.

Best regards,
Larry

[David Ranch]

Hello Larry,

While it was an excellent test to try an lower sampling rate device like an RTL dongle, it IS work mentioning that Airspy unit supports a 2.5MSPS mode as well as a bit stuffing mode to work around poor USB throughput.   You also might be running an older version of the Airspy firmware so you might checkout the Airspy website or my Airspy chapter on how to do some upgrades, test the alternative USB mode, etc:

   http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#42g.airspy-sw

It's worth noting that the Airspy unit running at 2.5MSPS will still blow away any inexpensive RTL dongle (better sensitivity, no DC spike, etc).  It's also worth mentioning that the USB stuffing feature *will* increase the CPU utilization so it could just trade off one problem for another.

So, I switched to the RTL-SDR dongle set to 1800 SPS and broadcast FM
reception.  The audio from gqrx was slightly improved, in that it could be
coaxed to output continuous audio by setting the mode to UCW.  Of course, the
FM audio was not intelligible with that mode, but it was continuous for the
first time.

If you start Gqrx from the CLI and listen to a broadcast station:

   - What are you setting the decimation to in the device configuration area?  Should be ZERO to start off with
   - what is your AFFT setting?  You should set this to as low as possible to start off with (only impacts the waterfall view)
   - What is your FFT refresh rate?  Consider dropping that down to like 5 frames per second to start (only impacts the waterfall view)

See for a few other ideas:

   http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#42j4.gqrx-perf-issues
 
--David
KI6ZHD