gqrx & pulseaudio

[Pedro Colla (LU7DID)]

Hi,

I'm posting this question originally (and mistakenly) posted as an issue at GitHub related to the usage of gqrx and pulseaudio on a Raspberry Pi mod 3.

I'd installed gqrx 2.11.5 as downloaded from the gqrx.dk site (https://github.com/csete/gqrx/releases/download/v2.11.5/gqrx-sdr-2.11.5-linux-rpi3.tar.xz) and proceed with the installation as indicated by the readme file included to install all dependencies. I'd used binaries, not compiled anything.

Using rtl-sdr as the radio source gqrx works perfectly using the USB sound dongle (listed as alsa hw:CARD=AUDIO,DEV=0). I'm able to receive both VHF and HF with the correct sampling mode.

Then I'm trying to use either wsjtx or fdigi by using a virtual cable thru pulseaudio. I've installed version 10.0. Having tested the configuration with another configuration where mplayer ends being the application source it does work Ok.

In such configuration when I open pavucontrol I'm able to assign one virtual cable (virtual0) as the target for mplayer and then capture it with either wsjtx or fdigi.

However, when I try to replicate the same configuration with gqrx it doesn't work. gqrx isn't listed as an application in the playback tab of pavucontrol. gqrx offers as output devices:

 

Default

bcm2835 ALSA -(hw:0,0)

bcm2835 ALSA:IEC958/HDMI

USB AUDIO audio(hw:1,0)

sysdefault

dmix

default

Which I believe none of them are the virtual cables implemented by pulseaudio.

I'd surveyed previous entries with similar problems but they either doesn't seems to be the same nor related to this particular version of gqrx.

Any help would be very much greatly appreciated, Pedro LU7DID

[Alexandru Csete]

Hi Pedro,

The Raspberry Pi desktop does not use pulseaudio by default and
therefore gqrx for the raspberry pi has been built with alsa audio
output, not pulseaudio. However, if you have pulseaudio installed one
of the "default" devices should be pulseaudio output. There should
also be an output device called "pulse" so something is not quite
right there.

Do you have the libasound2-plugins package installed?

Some time ago I tried running gqrx with pulseaudio output on the
raspberry pi, but it did not have enough CPU, so that's why I added
the ALSA backend. You can also create virtual audio devices in ALSA
and it is much more lightweight than pulseaudio.

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/7aaa5ff6-20b6-4727-8ad5-91f76bead462%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Pedro Colla (LU7DID)]

Hi Alex,

Following your advice I did removed pulseaudio altogether and created a virtual device (sudo modproce snd-aloop). Triggering gqrx the "loopback port" shows up as an option (see figure attached). Choose the first loopback. But when triggering wsjtx the available audio devices has a different label. Choosing the first loopback (DEV=0) yields no sound. The CPU usage is quite high when both are running (70% or higher) and performance turns sluggish.

Perhaps you are telling me a different approach but I am not grasping it correctly, would appreciate very much if you can elaborate a little in your proposal (or point me into some link where it's implementation is explained).

I'd attached several images that might help my explanation.

Thanks and best regards, Pedro LU7DID 

[Alexandru Csete]

That was more or less what I meant.

However, I need to stress that gqrx on the raspberry pi is very experimental and that the raspberry pi is a rather weak computer when it comes to running an SDR like gqrx. If CPU load is too high, try reducing sample rate, FFT rate and FFT size. Also, note that running gqrx remotely introduces a whole new set of variables that may reduce performance.

Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/gqrx/1f7afdeb-4ec2-4bae-bbd3-bb6c140985da%40googlegroups.com.

[Pedro Colla (LU7DID)]

Hi Alex,

Thanks for the support. I'm not concerned by the CPU usage as yet, this is an optimization whose time would come later. I'm trying to get the basic behaviour right first (even with sluggish response or choppy audio). At this point no audio reach wsjtx from gqrx. I'm not running gqrx remotely, in the sense of using a remote TCP source, it's just an X11 connection as the whole thing is running within the RBPI.

So do you think that "Loopback PCM (hw,1,0)" as shown in gqrx actually is the same object than "hw:CARD=Loopback,DEV=0" as shown by wsjtx? Not quite familiar with ALSA but there are half dozen other "Loopback" being shown.

¿Do you think in any other way to make gqrx & wsjtx (or fldigi for that matter) to work together?

Thanks in advance, Pedro LU7DID

[Alexandru Csete]

Sorry, I have no idea and can not test at the moment.

Like I said in my first message, even when gqrx plays through ALSA to
a default device, it should show up in pulseaudio mixer. The fact that
you do not see a sound card named "pulse" in gqrx suggests that some
package might be missing.

Alex

On Sun, Nov 11, 2018 at 4:06 PM Pedro Colla (LU7DID)
<pedro...@gmail.com> wrote:
>
> Hi Alex,
>
> Thanks for the support. I'm not concerned by the CPU usage as yet, this is an optimization whose time would come later. I'm trying to get the basic behaviour right first (even with sluggish response or choppy audio). At this point no audio reach wsjtx from gqrx. I'm not running gqrx remotely, in the sense of using a remote TCP source, it's just an X11 connection as the whole thing is running within the RBPI.
>
> So do you think that "Loopback PCM (hw,1,0)" as shown in gqrx actually is the same object than "hw:CARD=Loopback,DEV=0" as shown by wsjtx? Not quite familiar with ALSA but there are half dozen other "Loopback" being shown.
>
> ¿Do you think in any other way to make gqrx & wsjtx (or fldigi for that matter) to work together?
>
> Thanks in advance, Pedro LU7DID
>
> El domingo, 11 de noviembre de 2018, 6:14:43 (UTC-3), Alexandru Csete escribió:
>>
>> That was more or less what I meant.
>>
>> However, I need to stress that gqrx on the raspberry pi is very experimental and that the raspberry pi is a rather weak computer when it comes to running an SDR like gqrx. If CPU load is too high, try reducing sample rate, FFT rate and FFT size. Also, note that running gqrx remotely introduces a whole new set of variables that may reduce performance.
>>
>> Alex
>>
>>
>>
>> On Sun, Nov 11, 2018 at 4:35 AM Pedro Colla (LU7DID) <pedro...@gmail.com> wrote:
>>>
>>> Hi Alex,
>>>
>>> Following your advice I did removed pulseaudio altogether and created a virtual device (sudo modproce snd-aloop). Triggering gqrx the "loopback port" shows up as an option (see figure attached). Choose the first loopback. But when triggering wsjtx the available audio devices has a different label. Choosing the first loopback (DEV=0) yields no sound. The CPU usage is quite high when both are running (70% or higher) and performance turns sluggish.
>>>
>>> Perhaps you are telling me a different approach but I am not grasping it correctly, would appreciate very much if you can elaborate a little in your proposal (or point me into some link where it's implementation is explained).
>>>
>>> I'd attached several images that might help my explanation.
>>>

> To view this discussion on the web visit https://groups.google.com/d/msgid/gqrx/ac6b4321-1801-44d1-985c-85f708ce924f%40googlegroups.com.

[Pedro Colla (LU7DID)]

Hi Alex,

Thank you for your time on following up on this thread. I believe it's the other way around, is gqrx the one not showing up in pavucontrol, as the originating application. It's the way it works with other setups and not in this case.

Perhaps at some future time you might give a thought to the issue and find out a workaround, as it is today it seems there is no way gqrx can work with either wsjtx or fldigi. If that happens I could gladly offer my time to act as tester.

Best regards, Pedro LU7DID

[Alexandru Csete]

Okay, let me try to say this one last time: If your system is
configured correctly and all the necessary packages/plugins are
installed, and you choose a pulseaudio compatible output in gqrx
("default" or "pulse" should work), then gqrx will show up as "ALSA
plug-in [gqrx]" in pavucontrol. See the attached screenshots.

Good luck!

Alex
On Sun, Nov 11, 2018 at 7:08 PM Pedro Colla (LU7DID)

> To view this discussion on the web visit https://groups.google.com/d/msgid/gqrx/719a7dad-588d-49a6-88ac-7713d5a2559b%40googlegroups.com.

[Pedro Colla (LU7DID)]

Hi Alex,

Thank you for your patience. It's somewhat complex to understand which are the necessary packages/plugins, I do have installed all the ones informed in the installation instructions and some others discovered as tests moved forward.

Your images did help a lot actually, and configuring gqrx like them I did actually was able to see gqrx listed in pavucontrol; it seems the issue moved into some different place. Now it's listed in one moment and erased in the next (yes, it flicks on and off), piping thru a virtual cable it does connect with wsjtx although the decoding of a local wspr signal is erratic.

It seems there is some quite severe performance issue involved, CPU usage is very high and everything is sluggish (that, alone could explain the failure to decode as the processor has "visible" timing issues).

Meanwhile gqrx shows scores of errors like

portaudio_skink::work(): Error writing to audio device: Output underflowed

ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred

With a very high frequency, say 2 per second, which is about the same frequency of the on/off behaviour of gqrx at pavucontrol.

Reducing the sample rate to the minimum seems to mitigate the problem, but doesn't solve it.

I'll setup some local tests with RBPI attached to a keyboard/monitor in order to see if the network overhead of being accessed remotely has something to do with the problem (or mitigates it further).

Thanks, Pedro LU7DID