gqrx on raspberry pi with no monitor: "Connection refused"

[R. D. Powers]

Referencing an old thread: https://groups.google.com/forum/#!topic/gqrx/YaQsxb8T3ms

I was running into a similar pulseaudio "connection refused" error starting gqrx with pulseaudio and found it pretty frustrating so I dug in.  

My use case was the "headless ssh" one.  I started ssh from a linux desktop running ubuntu 18.04 into a raspberry pi running ubuntu 20.04, and this rpi has no monitor attached. I use the '-X' flag to ssh so the graphical output of gqrx goes back to the linux desktop via a "ssh tunnel".

I saw the suggestion of recompiling gqrx to not use pulseaudio and use alsa instead, but I found that to be counter productive in general and ineffective for my use case.

Googling brought up a thread with someone debugging a different pulseaudio connection refused issue that brought a lot of good tips:

https://pulseaudio-discuss.freedesktop.narkive.com/2cCmvy41/how-to-start-a-pulseaudio-application-as-a-daemon-with-systemd

The best tip was to set the environment variable PULSE_LOG to 99 to see what exactly it was trying to connect to, then start gqrx.

You can do it in one line (and it doesn't stay set)

    $ PULSE_LOG=99 gqrx

Or two (and it stays set till you log out)

    $ export PULSE_LOG=99 

    $ gqrx

So, what does pulseaudio try to connect to?  Their FAQ ( https://www.freedesktop.org/wiki/Software/PulseAudio/FAQ/ ) has an entry "How do the PulseAudio libraries decide where to connect to?" that describes exactly what it connects to and in what order.

In my case, I was using the ssh tunnel so I expected it to be using the DISPLAY variable to connect the sound back to the pulseaudio server running on the linux desktop.  The pulseaudio examle page ( https://wiki.archlinux.org/index.php/PulseAudio/Examples#PulseAudio_over_network ) is a good reference.  The problem was the section titled "Selecting the Server" doesn't make sense when it says to run pavucontrol on the remote server -- I can't since it's headless!  So I fell through to "When everything else seems to fail" and did what it said.

Yet it still didn't work -- why?  The "PULSE_LOG=99 gqrx" trick showed me what it was trying to connect to, which was "tcp4:mydesktop:4713 and that didn't work because my local network has a terrible admin (me!) and the raspberry pi did not know what IP address to use for 'mydesktop'!   From what I can tell, 'ssh -X' communicates the hostname via the setup protocol and this is what is provided to pulseaudio on the client.

So, how to fix this?  Either create an /etc/hosts file on the rpi, or just tell the pulseaudio code in gqx exactly what IP address to use to talk to the pulseaudio server  on the desktop linux system:

    $ PULSE_SERVER="tcp:192.168.1.16:4713" PULSE_LOG=99 gqrx

And this worked.

So, what if I wanted to use the raspberry pi's headphone jack instead of sending the audio back to my desktop?  The pulse log output shows you things it's trying to connect to and one of them is a local (unix) socket and you can force the pulseaudio code in gqrx to use that:

    $ PULSE_SERVER="unix:/run/user/1000/pulse/native" PULSE_LOG=99 gqrx

Note that the 1000 in that path is the userid that started the pulse server.  The way pulseaudio works, this normally is the user id number of the user main user of the system.  You can see what one you are logged in as via:

    $ id

In my case the output starts with "uid=1000" which matches the above. It also includes the pulse-access group which I think is necessary.

The first link above was a case of debugging the problems when the current running user id is not the one that pulseaudio is running under.

You can see the listening socket via:

    $ sudo netstat -lp | grep pulse

If the ID in the output of the 'id' command doesn't match the listening socket number then you are in a different use case than I am, but maybe the link above can give you a clue on how to address that.  If there is no output then systemd isn't running or the pulseaudio service didn't start.  This wasn't the case for me so I didn't have to debug that kind of issue.

After doing all the above, gqrx runs and I am happy.  I find gqrx using rpi4b with 4g memory is slow decoding a local FM broadcast station.  I'm new to gqrx so I'll have to figure out how to reduce its CPU usage. This was with HackRF1 radio.  I switched to rtl-sdr and it worked better presumably because it was using less USB bandwidth.  I also dialed down the FFT rate and reduced the window size to reduce the amount of data per update.  

I'm wondering if anyone has any data whether or not there are performance issues running with this configuration i.e. gqrx runs on remote host but uses ssh tunnel to send back X windows updates and sound goes via pulseaudio?  I suppose I can get rid of the ssh tunnel and just use X and see if that provides better performance.  Also I can go find a monitor and run it the normal way, but I would think having to run an X sever locally would mean less performance rather than more, and if I want remote operation I'd have to use vnc which would be more load on the rpi.

Regards,

RDP