Date   
linux : pip audio from any demodulators to others programs

remis
 
Edited

Hello
I'd like to register (check also) low activity around DMR repeater during my working day. Thus post analysing audio file.
In Sdrangel for some modulation  (FM , AM , or IQ file ) we can use UDp sink module . Next , netcast, udp (see multimon example)  can play ( store ?) audio file. 
But for DSD demodulator I have only one solution : send sdrangel audio to virtual cable. Pip virtual cable to other audio registering programs.
Please could you confirm this is the only solution today, for DSD and freeDV modulator?

After more reading : May be thesolution is here  with UDP to nc...https://github.com/f4exb/sdrangel/wiki/Networking-audio

Many thanks
Remi F4BAD

Re: Poor audio with Linux, perfect audio with Windows

Steve (SDRA)
 

Thanks Kevin,

There are no untoward messages noted, sadly :(

@Bob, what kernel do you have in use? Maybe I'll try Ubuntu 19.10 with the same kernel and see what that does.

Kind regards,

Steve

On 1/15/20 4:26 PM, Kevin Stabel wrote:
Hi,

Just an idea, but you might have some type of hardware/driver/firmware issue.

Fire up a terminal, and run "dmesg -w", then launch sdrangel, and keep an eye for any messages that appear in the terminal.

Re: RSPduo support

Alex DEKKER
 

Yes it will work locally [I have used it with the RSP1].

alexd


On 16/01/2020 14:22, Ron Liekens wrote:
Thanks for the info. Can I activate SoapySDR on the same machine where SDRangel is runing on, or do I have to use another machine with SoapySDR server software like a Raspberry Pi4 and connect via Ethernet?

regards, Ron


Re: RSPduo support

Ron Liekens
 

Thanks for the info. Can I activate SoapySDR on the same machine where SDRangel is runing on, or do I have to use another machine with SoapySDR server software like a Raspberry Pi4 and connect via Ethernet?

regards, Ron

Re: RSPduo support

Edouard Griffiths
 

Hi,

the short answer is no. To elaborate more SDRPlay support is closed source and importing the binary blob into an open source project is not easy to say the least. I don't see why I would promote the choice of closed source support while some great projects are open source: LimeSDR, BladeRF, Airspy, HackRF, RTL-SDR to name just a few. However you can work around this using SoapySDR.

Brgds, Edouard.

RSPduo support

Ron Liekens
 

Are there plans to support the various SDRplay models?

regards,  Ron

Re: Troubleshooting a data throughput upper limit ~60.244MB/s ?

pipe2null
 

Thanks!

Looks like there are quite a few things for me to try, including the bits from the other thread RE audio, like building my own RT kernel, or switching to a distro that has a kernel manager (Arch?  Manjaro?  I forget which ones have one with precompiled RT kernels...).  As far as my personal use goes, I'm working through the initial learning curves since I have a software background but I'm new to SDR, and I'm trying to get a dependable dev machine/environment configured at the same time I'm getting a feel for the quirks and idiosyncrasies of the Lime hardware/software stack.  As soon as I'm solid enough with that and I've determined the MAX I can get out of my Limes, then I have a list of SDR related dev projects to jump into.  GNU Radio or Pathos (or something else) for prototyping?  For casual use listening purposes though, I still want a Linux friendly SDR# equivalent and sdrangel seems like a good (best?) option.  Plus the channel analyzer/scope is exactly what I wanted for reverse engineering the wireless protocol of some simple commercial devices I want to directly communicate with my desktop. 

For "practical BW" requirements, I'm still working that out.  I bought my Lime to use as a general purpose wireless device debugger/monitor/base station for (hopefully) multiple protocols and (hopefully) multiple frequency ranges.  I got the Lime mini for casual listening purposes with better BW than my RTL-SDR plus a specific wider BW project to capture full FM band with multi-channel decode up to CPU max.  Once I have code built for that, I can apply it to any band: "TIVO" ham broadcasts, push notifications from Arduino devices to my smartphone, etc.  At least that's the general idea of projects to start with.  Should be interesting, at least after I get past the initial learning curves, plus what I believe are actual bugs with Lime's software stack.  TBD.

Again, thanks for the software, and thanks for being attentive to your users!  Not all open source developers do that.

Re: Poor audio with Linux, perfect audio with Windows

Kevin Stabel
 

Hi,

Just an idea, but you might have some type of hardware/driver/firmware issue.

Fire up a terminal, and run "dmesg -w", then launch sdrangel, and keep an eye for any messages that appear in the terminal.

Kind regards

-Kevin


On Wed, Jan 15, 2020 at 5:10 PM Steve (SDRA) <steve-sdrangel@...> wrote:
Thanks Bob,

I installed a realtime kernel (4.19.0-6-rt-amd64) and set Pulseaudio to
request RT priority and associated permissions. It made a noticeable
difference (good) in that the glitches are much reduced but still present.

The TX audio quality - for me - is still very poor though.

I tried something different. I setup QSSTV to receive DRM on my (Linux)
desktop with an RTL dongle. On my laptop I used EasyPal to send DRM
pictures using my Pluto and SDR-Console (Windows). No adjustments, just
put the tx gain up a bit and go. 100% copy with SNR around 24dB. Good.

Rebooted the same laptop into Linux. Used QSSTV to send using Angel in
the same way. After a couple of hours tweaking to get it as good as I
can resulted in around 40% copy and a SNR varying between 9 and 14dB.

So, it's definitely only TX audio that I'm having a problem with.
Receiving appears to be solid.

One thing though. With SDR-Console the default 'bandwidth' for the Pluto
appears to be 550kHz. I couldn't get that low on Angel whatever I did
with decimation, FIR etc. Getting dizzy now...

Kind regards,

Steve

On 1/15/20 4:45 AM, Boudewijn (Bob) Tenty wrote:
> I use a Pluto SDR using Ubuntu 19.10 in a computer with eight cores
> and have no problem with the audio.
> I'm using a low latency kernel and maybe that may help in your case. 
> You can also change the priority of a program what you
> can do from the terminal with the 'renice' command.
>
> Bob VE3TOK
>
>



Re: Poor audio with Linux, perfect audio with Windows

Steve (SDRA)
 

Thanks Bob,

I installed a realtime kernel (4.19.0-6-rt-amd64) and set Pulseaudio to request RT priority and associated permissions. It made a noticeable difference (good) in that the glitches are much reduced but still present.

The TX audio quality - for me - is still very poor though.

I tried something different. I setup QSSTV to receive DRM on my (Linux) desktop with an RTL dongle. On my laptop I used EasyPal to send DRM pictures using my Pluto and SDR-Console (Windows). No adjustments, just put the tx gain up a bit and go. 100% copy with SNR around 24dB. Good.

Rebooted the same laptop into Linux. Used QSSTV to send using Angel in the same way. After a couple of hours tweaking to get it as good as I can resulted in around 40% copy and a SNR varying between 9 and 14dB.

So, it's definitely only TX audio that I'm having a problem with. Receiving appears to be solid.

One thing though. With SDR-Console the default 'bandwidth' for the Pluto appears to be 550kHz. I couldn't get that low on Angel whatever I did with decimation, FIR etc. Getting dizzy now...

Kind regards,

Steve

On 1/15/20 4:45 AM, Boudewijn (Bob) Tenty wrote:
I use a Pluto SDR using Ubuntu 19.10 in a computer with eight cores and have no problem with the audio.
I'm using a low latency kernel and maybe that may help in your case.  You can also change the priority of a program what you
can do from the terminal with the 'renice' command.

Bob VE3TOK

Re: Troubleshooting a data throughput upper limit ~60.244MB/s ?

Edouard Griffiths
 

Hi,

I didn't perform a complete check in the code but probing here and there shows that the return call of all LMS_ function calls are checked and a qCritcal or a fprintf to stderr is done if there is an error so you should be able to see something in the console in case of error. I also encountered the kind of behavior you describe when pushing the S/s towards the top. I usually proceed in 10 MS/s steps and don't go right away from a few MS/s to the top. Usually going up to 10 MS/s is not an issue then things start to behave a bit strangely and I also encountered the case when the software thinks the sample rate has increased but the hardware does not follow. As the control of the LMS goes on the same line as the data there might be some issues when a high data rate flows and control blocks may be dropped the same way as data blocks are dropped therefore some controls may be lost in the blue. Usually fiddling with some other controls than the sample rate eventually get me through (I found that lowering the hardware decimation was rather efficient). I have noticed that the overflow and dropped packet indicators go red for a short while after each change. This may indicate that things are a bit shaky in the transient period.
 
About crashing when using the WFM demod. It appears in the log that the baseband sample rate is 40MS/s so supposedly at that point the sample rate on the Lime side is set to 40MS/s without software decimation (80MS/s is out of range). That's a lot when you only need ~250kHz of bandwidth for the WFM demod. This is the sort of corner case that is not exercised a lot if at all. You need a high sample rate only when you need to process a large bandwidth in the demodulator. Only the ATV demodulator needs a few MHz bandwidth when using standard TV modes (625 lines 25 fps for example). Also the Channel Analyzer takes an arbitrary bandwidth and I would be more concerned if one of these two would fail. Although the WFM demod processes a fairly large bandwidth 40 MS/s is still 160 times 250 kS/s so it puts a lot of strain on the decimation chain. At best the half-band decimators chain will do most of the job and it still needs 7 stages to decimate by 128 (closest power of two). The chain length is arbitrary but usually one would not exceed 4 or 5 stages. 
 
Concretely if you want to see the full 20 MHz broadcast band while listening on one program or to two programs far apart on the band there is another option with the "LocalSink" plugin that explicitely decimate down to a part of the band and let you have more control on the decimation chain. It can also help in splitting the workload among threads. I do not go in all details here briefly you combine the "LocalSink" channel plugin with the "LocalInput" device plugin in another device set where you will put the final WFM demod. I have used this technique for QO-100 reception to see the upper and lower parts of the narrow band downlink with good enough details while having a single receiver. Below is a schematic of the deployment you can elaborate more on this to fit your exact use case:

R0:                                                                    R1:
Device:                             Channels:                          Device:                     Channels:   
RTL-SDR       ----- 280 kS/s ---->  -- LocalSink ---- 140 kS/s ------> LocalInput -- 140 kS/s -->  -- SSB demod 
SR: 1120 kS/s  489.535 - 489.815       decim: 2    489.535 - 489.675 MHz                           -- ...
decim: 4                               lower half 
                                       linked to R1 
                                                                       R2:
                                                                       Device:                     Channels:   
                                    -- LocalSink ---- 140 kS/s ------> LocalInput -- 140 kS/s -->  -- SSB demod
                                       decim: 2    489.675 - 489.815 MHz                           -- Frequency tracker (489.800)
                                       upper half                                                  -- ...
                                       linked to R2
                                         
Note : the downconverter (LNB) and transverter shift makes me "see" 10489 MHz as 489 MHz.

Brgds, Edouard.

Re: Poor audio with Linux, perfect audio with Windows

Boudewijn (Bob) Tenty
 

I use a Pluto SDR using Ubuntu 19.10 in a computer with eight cores and have no problem with the audio.
I'm using a low latency kernel and maybe that may help in your case.  You can also change the priority of a program what you
can do from the terminal with the 'renice' command.

Bob VE3TOK

On 2020-01-14 15:04, Steve (SDRA) wrote:
Dear all,

Because I seem to be having persistent audio issues with SDRAngel under Linux with LimeSDR-Mini that I can't get to the bottom of, I've taken a different direction to illustrate them. Perhaps I'm expecting the impossible, or maybe some of you can check your installations and tell me if you do, or do not have this problem.

Using my I7 laptop, I transmit low-power SSB with output from Fldigi set to PSK31 mode and using the T/R button send idle (two-tones I believe).

On my desktop (AMD Ryzen 5 1600 Six-Core Processor) and SDRAngel I receive with an RTL dongle. TX power and gains are adjusted sensibly; these are 2 metres apart.

I used my ADALM Pluto to transmit to see if it suffers the same as the Lime. It does.

The attached image 'linux-sdrangel.jpg' shows the /best/ I could obtain with SDRAngel and Linux. The S/N ratio is 43dB and the imd shows as -41dB at best. You can see audio glitches in the waterfall and these make the imd drop to maybe -32dB. You can hear the glitches. These same glitches cause a 50% failure rate sending a largish DRM picture; the MSC and/or FSC sync is lost for each glitch.

Image 'windows-sdrconsole.jpg' (sorry!) shows the receive quality from the same hardware booted into Windows 7. Again Fldigi feeding SDR-Console via VB-Cable software audio loopback. You can see the difference is obvious. The waterfall is clean (ignore frequency stability of the Pluto) and the S/N ratio is now 46dB (+3dB) and the imd is -47dB (6dB better minimum, 15dB better during glitches).

The exact same glitches under Linux/SDRAngel are there for three different computers - the laptop (Mint 18.0), my desktop (Mint 18.3) and my J4105 SBC (Debian 10 Buster).

I have no idea if this is an underlying Linux issue with Debian and derivatives, or SDRAngel, or more likely I'm doing something so stupid I just can't see it. I couldn't get the Windows binary of SDRAngel to work. I'll go back and revisit that.

Please help! Even if all you can do is confirm to me that the output from your own hardware is like my Windows example; clean.

Kind regards,

Steve



-- 

When you change the way you look at things, the things you look at change 

Max Planck

Re: Troubleshooting a data throughput upper limit ~60.244MB/s ?

pipe2null
 

Thanks for checking that!

I did some additional checking using my local commercial FM stations as a visual signal reference I am familiar with using center frequency of 98MHz ("high" antenna port for both with appropriate filter settings) and only varying S/s.  For the LimeSDR/mini running Angel on Linux, I figured out that my ~60.244MB/s max was coming from some wierd internal Lime state.  

Using the mini, if I start with a known working value like 10MS/s and use the angel's ui to increment S/s while continuously running, it will increment ok to 22.968749 MS/s and you can see the expected changes in the waterfall, but between 22.968750 MS/s up to and including 30.156250 MS/s, the ui scale numbers will change but the waterfall/incoming frequency range does not: the signal is live and the waterfall matches signal, but the BW of the shown signal is visually still the previous 22MHz BW which is the last "good" configuration, meaning it does not appear that the Lime updated it's config to match what angel was telling it to do.  But magically, when you go beyond the upper transition between 30.156250 MS/s and 30.156251 MS/s, it starts working again as expected and only then do I get ~90MB/s data speeds. The same things happens while decrementing down from 30.72MS/s, so there is a "no-man's-land" in there with a lower transition point between 22.968749+1 MS/s and upper transition point between 30.156250+1 MS/s.

I get the same behavior with a full sized LimeSDR, but the lower "no mans land" transition point is between 20.000000 MS/s and 20.000001 MS/s and there is no upper limit, even at 61.44MS/s the ui is still showing the same live signal that in reality is only 20MHz of BW.  So it appears that my LimeSDR is maxing at ~60MB/s data rate simply because the internal configuration is not going above 20MS/s!!!  WTF?!?

Is Lime's API not returning an error or throwing an exception if software is setting a LimeSDR/mini to an unsupported configuration, or if Lime for whatever reason refuses to change config?  Does SDRangel have any command line switches that I should try?

One additional datapoint, angel's data freezes and/or app crashes pretty consistently when setting a S/s that transitions OUT of no-mans-land, incrementing above/through the upper bound or decrementing below/through the lower bound.  The data stays frozen until you set a known good S/s setting for the second time (first time is transition OUT).  Full app crashes (related to this specific repro) only happen when the WFM demodulator is running.

Debug spew sample from console (the "basebandSampleRate" varies):
2020-01-14 18:23:43.398 (D) LimeSDRInput::getSRRange: min: 100000.000000 max: 61440000.000000
2020-01-14 18:23:43.398 (D) WFMDemodBaseband::handleMessage: DSPSignalNotification: basebandSampleRate:  40000000
Floating point exception (core dumped)
 
All the software I'm using (SDRangel and LimeSuite) was built fresh on my Linux machine in the last couple days, I think January 12, 2020, so whatever was current as of that day.

So...  All that, and I'm still nowhere near figuring out what's causing all those dropped data packets.

Re: Troubleshooting a data throughput upper limit ~60.244MB/s ?

Edouard Griffiths
 
Edited

I just tried with a Lime Mini (I have hard limited sample rate to 30.72 MS/s as per specs) and I can run it up to 30 MS/s (thus ~90MB/s) without issues. However to reach this sample rate I had to set the hardware decimation down to 4 (then I can get it back to 8). Don't know why really this seems related to LMS7002M internals. Note that I do some averaging on the spectrum so there's a bit of work done there. This runs on a 6 core with HT (thus 12 CPUs) actual CPU frequency is between 1100~1600 MHz and it runs at ~90% scaled to 1 CPU (~6.5 % total). USB is USB3.

Re: Troubleshooting a data throughput upper limit ~60.244MB/s ?

Edouard Griffiths
 

Hello,

all these indicators use LMS_GetStreamStatus that fills a lms_stream_status_t structure. The indicator turns red when the count of underrun, overrun or dropeedPackets is positive (one indicator for each). These counters are sampled regularly about every second from the GUI. The LMS API documentation does not detail how these counters work and they do not seem to be continuous as eventually they return to 0 (the indicators light off at some point). It seems hard to me to guess any rule there. The LMS FIFO fill ratio is more straightforward. It is the ratio of FIFO fill over FIFO size and in Rx should be close to 0 for a sign of good health as the samples do not stack up in the FIFO. For Tx it is the opposite as you do not want the FIFO to deplete down to 0.

Brgds, Edouard.

Re: Troubleshooting a data throughput upper limit ~60.244MB/s ?

pipe2null
 

@Edouard: Can you think of any (non-Lime-bug) reason that the FIFO status bar on Angel's UI would show 0% but the dropped packet indicator would be almost solidly red?  I keep hearing the phrase "CPU bound" here and on Lime forums, but that makes no sense to me since multiple machines' CPUs have been nowhere near maxed out.  Plus, dropped packets occur somewhat linearly compared to sampling rate: you can hear them (plus red indicator) occasionally at lower sampling/data transfer speeds, but you can still hear clear but a little choppy audio all the way up at the max sampling rate.  Dropped packets SHOULD be exponentially, not linearly, related: when you are close but slightly above the "max usable" data rate you should see a few dropped packets and dropped packets should increase exponentially the further beyond the "max usable" you go, but that is not the behavior that I'm observing... 

Bizarre:  Today I launched sdrangel on Linux and my Lime-mini got the full 30.72MS/s at ~92MB/s with a nearly solid red dropped packet indicator.  AFAIK, I made zero changes to configuration.  Audio is clear but choppy for FM radio stations at full BW/sample rate.  Dropping the rate down to 20MS/s gets ~62MB/s but still has a nearly constant red dropped packet indicator.  The FIFO status shows 0% across the board.  Doesn't make sense.

Hmmm...  I've heard of other people hitting a data throughput speed issue with Lime, but it was usually assumed to be a USB cable/controller/etc problem or an underpowered CPU.  If Steve's CPU is not maxed out, I'm curious if were are both hitting the same problem.

Also, THANKS for sdrangel, especially the channel analyzer/scope!

Poor audio with Linux, perfect audio with Windows

Steve (SDRA)
 

Dear all,

Because I seem to be having persistent audio issues with SDRAngel under Linux with LimeSDR-Mini that I can't get to the bottom of, I've taken a different direction to illustrate them. Perhaps I'm expecting the impossible, or maybe some of you can check your installations and tell me if you do, or do not have this problem.

Using my I7 laptop, I transmit low-power SSB with output from Fldigi set to PSK31 mode and using the T/R button send idle (two-tones I believe).

On my desktop (AMD Ryzen 5 1600 Six-Core Processor) and SDRAngel I receive with an RTL dongle. TX power and gains are adjusted sensibly; these are 2 metres apart.

I used my ADALM Pluto to transmit to see if it suffers the same as the Lime. It does.

The attached image 'linux-sdrangel.jpg' shows the /best/ I could obtain with SDRAngel and Linux. The S/N ratio is 43dB and the imd shows as -41dB at best. You can see audio glitches in the waterfall and these make the imd drop to maybe -32dB. You can hear the glitches. These same glitches cause a 50% failure rate sending a largish DRM picture; the MSC and/or FSC sync is lost for each glitch.

Image 'windows-sdrconsole.jpg' (sorry!) shows the receive quality from the same hardware booted into Windows 7. Again Fldigi feeding SDR-Console via VB-Cable software audio loopback. You can see the difference is obvious. The waterfall is clean (ignore frequency stability of the Pluto) and the S/N ratio is now 46dB (+3dB) and the imd is -47dB (6dB better minimum, 15dB better during glitches).

The exact same glitches under Linux/SDRAngel are there for three different computers - the laptop (Mint 18.0), my desktop (Mint 18.3) and my J4105 SBC (Debian 10 Buster).

I have no idea if this is an underlying Linux issue with Debian and derivatives, or SDRAngel, or more likely I'm doing something so stupid I just can't see it. I couldn't get the Windows binary of SDRAngel to work. I'll go back and revisit that.

Please help! Even if all you can do is confirm to me that the output from your own hardware is like my Windows example; clean.

Kind regards,

Steve

Re: Troubleshooting a data throughput upper limit ~60.244MB/s ?

Steve (SDRA)
 

Hello pipe2null,

As another data point, with my LimeSDR-Mini I only get 11.1MS/s for 33.33MB/s maximum with one red 'dropped packet' indicator every ~15 seconds with a Broadscast FM demod. sdrangel at 192%, Xtigervnc 27% (headless, with waterfall and spectrum turned off) and pulseaudio 3%.

This is on an Intel J4105 SBC (quad-core Celeron 2.3GHz burst with USB 3) so I guess it's all down to being CPU bound.

Kind regards,

Steve

On 1/13/20 10:21 PM, pipe2null wrote:

I'm using both LimeSDR and LimeSDR-mini (not plugged in at the same time) and regardless of settings, I keep hitting a maximum receive rate of ~60.244MB/s no matter what S/s I use.  The highest data rate I've been able to get without the red "Dropped packets" indicator flashing is around 10MS/s even with the full sized LimeSDR.

Re: segfaults, possible audio related

Steve (SDRA)
 

Hello Edouard,

Many thanks for the reply.

I have now rebuilt with Debian 10 (Buster) from scratch with the default Pulseaudio installed. I still have audio problems with levels and distortion using 4.12.5 installed from the released .deb archive but I will start another thread after I've been through and checked I'm not being particularly daft :)

Kind regards,

Steve

On 1/13/20 9:33 AM, Edouard Griffiths wrote:
AFAIK SDRangel relies on Pulseaudio for audio processing. If you remove it then you are on your own.

Re: Troubleshooting a data throughput upper limit ~60.244MB/s ?

Edouard Griffiths
 

I do not know how SDR# present things but the indicators and the throughput values are those given by the LimeSuite library functions.
Brgds, Edouard.

Troubleshooting a data throughput upper limit ~60.244MB/s ?

pipe2null
 

I'm using both LimeSDR and LimeSDR-mini (not plugged in at the same time) and regardless of settings, I keep hitting a maximum receive rate of ~60.244MB/s no matter what S/s I use.  The highest data rate I've been able to get without the red "Dropped packets" indicator flashing is around 10MS/s even with the full sized LimeSDR.  I have verified there is no problem with USB cable/controller (no difference when plugged in directly) and on the Windows machine I used SDR# to verify USB 3.0 cables/controller/etc can get 40MS/s with no audible dropped packets and can get up to the full 60MS/s with frequent audible dropped packets but still getting a reasonably smooth waterfall in the SDR# UI.

I hit the same issue on both Linux and Windows (different machines).  Both machines have a reasonably beefy CPU and plenty of available RAM, both cases CPU max is between 30%-50%.

I use Linux almost exclusively, aside from those rare occasions like today that I need to use Windows-only software to troubleshoot something.  Since SDRAngel seems to be the go-to SDR software on Linux, I'm anxious to fix whatever problem I'm hitting.

Any idea why I have a "speed limit", and how might I go about fixing it?