Date   
Re: Poor audio with Linux, perfect audio with Windows

Edouard Griffiths
 
Edited

Hello,

I haven't had time to try to reproduce using the details given by Steve below. However this seems to confirm that this is related on how the audio system and the chain all the way up to the device behave in terms of sample rate. So it may work or not depending on so many details. I still have not a definite idea on making this more robust. One thing though: you do not use any software interpolation in the "device" part so all the strain is transferred to the channel interpolator and it may not be as optimized as the device one which is more straightforward. So you may want to try this in particular with the SSB modulator you don't need more than 48 kS/s in the baseband so to end with 2.5 MS/s if you interpolate by 32 you are down to 78.125 kS/s in the baseband. You may also want to choose a device sample rate that makes it fall on a multiple of 48k like : 48*2 = 96, 96*32 = 3072 kS/s. This will have the effect of by-passing the first rational resampler (however it runs at a relative low rate) and this will generally produce a cleaner signal.

You can find an overview of the internals here: https://github.com/f4exb/sdrangel/wiki/Developers-notes 

Brgds, Edouard.

Re: Poor audio with Linux, perfect audio with Windows

Boudewijn (Bob) Tenty
 

The kernel I use is  5.3.0-26-lowlatency #28-Ubuntu SMP PREEMPT  (Ubuntu 19.10)

I did a transmission test this evening with the Pluto sdr using NFM and a (usb) microphone.
I didn't hear any or see any audio interruptions on the modulation - This was tested on a I7-3770K CPU (Ivybidge)
Microphone audio sample rate was  48000 using pulse audio.

I will repeat this at a later date with SSB.

73,

Bob VE3TOK

On 2020-01-22 14:24, Steve (SDRA) wrote:
I reformatted the SBC and installed Ubuntu 19.10. The audio artefacts were different; better. The attached image 'ubuntu1910.jpg' shows the Channel Spectrum during a Fldigi PSK31 idle 'transmission' (2 tones) into the test sink.

@Bob mentioned he uses a low-latency kernel so the next thing I tried was to install that kernel. The audio artefacts were much better (see ubuntu1920-lowlatency.jpg) but they are still present occasionally.

These artefacts *are* visible on my transmissions via the QO-100 satellite and look just like they do here in the images, so really I'm reluctant to continue as it's clearly using more bandwidth than necessary.

I really don't know what's going on but this leaves me with an unusable combination of Linux/SDRangel on three different PCs (desktop, laptop, SBC). What a shame. My laptop has a Windows 7 partition and SDR-console works fine.

I'm not sure where to go next to figure this out...

Kind regards,

Steve

On 1/16/20 7:13 PM, Steve (SDRA) wrote:
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.

Re: Poor audio with Linux, perfect audio with Windows

Steve (SDRA)
 

I reformatted the SBC and installed Ubuntu 19.10. The audio artefacts were different; better. The attached image 'ubuntu1910.jpg' shows the Channel Spectrum during a Fldigi PSK31 idle 'transmission' (2 tones) into the test sink.

@Bob mentioned he uses a low-latency kernel so the next thing I tried was to install that kernel. The audio artefacts were much better (see ubuntu1920-lowlatency.jpg) but they are still present occasionally.

These artefacts *are* visible on my transmissions via the QO-100 satellite and look just like they do here in the images, so really I'm reluctant to continue as it's clearly using more bandwidth than necessary.

I really don't know what's going on but this leaves me with an unusable combination of Linux/SDRangel on three different PCs (desktop, laptop, SBC). What a shame. My laptop has a Windows 7 partition and SDR-console works fine.

I'm not sure where to go next to figure this out...

Kind regards,

Steve

On 1/16/20 7:13 PM, Steve (SDRA) wrote:
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.

Re: linux : pip audio from any demodulators to others programs

remis
 

Hello Edouards.
Many thanks for this confirmation. After many trials I use this solution , and also with squelch feature.: File is registered only when incoming audio is above 0. sdrangel is streaming even if internal squelch is close : padding with 0. Big file registered.
Without any virtual cable, here is the solution for all audio sequences in one file: with UDP 9998 16PCM in sdrangel audio section.

nc -l -u -p 9998 | sox -t raw -r 12k -e signed-integer -b 16 -c 1 - output.ogg sinc 200-4500 silence -l 1 0.1 1% -1 0.1 1%
for many file:
nc -l -u -p 9998 | sox -t raw -r 12k -e signed-integer -b 16 -c 1 - output.ogg sinc 200-4500 silence 1 0.5 1% 1 5.0 1% : newfile : restart

See for details :
https://ankitshah009.blogspot.com/2017/03/sox-of-silence-original-post.html
http://www.windytan.com/2013/07/squelch-it-out.html

For stand alone scanner next step could be remote control... registering current frequency
Regards

Re: Missing 'sampling device' in Windows 4.12.5

Wolfgang OE1MWW
 

Further tests:

sdrangel.log shows all devices & DLL had been loaded

Override high DPI in the sdrangel.exe setting activated

still no more devices in the 'sampling devices' list...

73's de OE1MWW
Wolfgang

Missing 'sampling device' in Windows 4.12.5

Wolfgang OE1MWW
 

Hi all,

running 4.12.5 in Windows 7 pro (YES, I know, 14 Jan 2020...) and in the sampling devices
I can see only:

File input
KiwiSDR
LocalInput
RemoteInput
TestSource

Tried to reduce my screen resolution from 1680x1050 to any lower setting
and did a 'factory reset' be deleting the Registry setting.

looks like, the issue is still open - or has anyone a clue for me please ?

73's de OE1MWW
Wolfgang

f4exb mentioned this issue on 11 Apr 2019

 

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

pipe2null
 

I installed a pre-built low latency kernel, and that appeared to help reduce dropped packets a tiny bit with my Limes, maybe a 10%-ish improvement.
So I built and installed a full real-time kernel, and that eliminated most dropped packets (red indicator only once every 10 seconds or so after device is initially started and configured).  This SHOULD be ZERO dropped packets during steady state when FIFO is 0% full, but I'll settle for the significant improvement for the time being.  Adjusting for my desired directories (/opt/kernel) and newer kernel version selected based on available patch versions (and which "normal" kernel version Mint is currently using), I used the directions here:
https://gnipsel.com/linuxcnc/uspace/linuxmint19-rt.html

The fully preemptive real time kernel took care of one problem for the most part (I still claim there is a Lime bug in there somewhere...), but I still have the "no-man's-land" problem with Lime configuration.  Not a big deal for my mini since you can still reliably set it to max 30.72 MS/s plus any S/s at or below 22 MS/s, but my LimeSDR refuses to accept any configs above 20 MS/s.  Getting the full 61.44 MS/s out of my LimeSDR is not about how I would use that much bandwidth, it is about making sure my hardware/software stack is configured and working properly and most importantly, working RELIABLY.  SDR# does not provide a dropped packet indicator, but you can see from the signal that Windows does not have the "no-man's-land" problem.

Anything else I should try to "force" a hardware configuration change?

Re: Poor audio with Linux, perfect audio with Windows

Steve (SDRA)
 

Thanks Bob, that's useful information.

I have carried out all my testing with the sample rate set at 1-2MS/s.

Kind regards,

Steve


On 1/17/20 7:23 AM, Boudewijn (Bob) Tenty wrote:
You can also limit the sample rate. Here I start to get small audio interruptions when set too high on reception,  let say above 4 MS/s. This without touching the priority.

Re: Poor audio with Linux, perfect audio with Windows

Steve (SDRA)
 

Dear Edouard,

Many thanks for the detailed reply. Here are some answers:

 - The issue is only with TX.

 - No issues with CW generated with the Morse keyer mode. The 'Tone modulation (1kHz)' mode is also good and generates a nice clean signal on the Channel Spectrum. When I was testing a while ago on QO-100 using the CW beacon, I had several people respond to my test transmission although I was only using about 1.5W into a DIY helix. The spectrum looked good on the BATC NB waterfall.

 - Playing a file is also good. There is a 'click' at the very beginning and then a nice clean signal on the Channel Spectrum.

You are correct, the problem is only when using the 'Audio input' function using the microphone icon. The interesting thing is that I think the TX Channel Spectrum shows bad things. I say 'I think' because I've never seen a 'correct' tone displayed.

The attached image shows the Channel Spectrum of a 1kHz tone at -10dB (48k sample rate, mono. Signed 16bit LE). SDRAngel shows it's pretty quiet, Pavucontrol shows about 40% strength and it sounds OK - not obviously distorted in my headphones. The spectrum looks.... interesting.

I am only using the SSB modulator. I did notice that the AM or NBFM don't seem to have a Channel Spectrum. I did previously try the ATV modulator during testing and the result looked awful with difficulties obtaining frame/line hold but I didn't spend much time adjusting things.

Apart from the Pluto, I originally tried with my LimeSDR-MIni which shows the same problem. The Test Output *also* shows the problem on the Channel Spectrum (also shown in the receiver).

Attachment 'sampling.jpg' shows the rates when I took the Channel Spectrum photo.

No frequency shift on the modulator.

Again, RX is flawless and TBH I find Angel nicely intuitive to use. I hope I can get to the bottom of this problem that seems to only affect me!

Many thanks for your help.

Kind regards,

Steve

On 1/17/20 10:30 AM, Edouard Griffiths wrote:
Hello,

let me try to recap things... Issue is with transmission right?

So I have a first bunch of questions:
  • Do you encounter the same issues with a CW transmission (either pure CW or in Morse beacon mode)?
  • And when playing a file?
I bet there are no issues and the problem starts when using audio input (mic or line) that is with the microphone icon engaged. Audio input is a bit different because the audio system and the radio system at the other end have different clocks so if there is a synchronization issue you may have this sort of glitches. Normally if this is the case something should show up in the log. However it is up to each plugin to collect audio so proper debug message may be missing.

So I have a few more questions:
  • Which modulator plugin are you using? Only SSB or did you try something else?
  • You are using Pluto, did you try with something else? Possibly the Test Output if you have no other hardware available?
  • What are the details of sample rate: raw device sample rate, interpolation factor?
  • Do you have a frequency shift on the modulator? If this is the case what is the value? (this is to figure out how the interpolation chain is built)

Brgds, Edouard.

Re: linux : pip audio from any demodulators to others programs

Edouard Griffiths
 
Edited

Hello Remi,

yes you can send the audio mix via UDP as explained in the Wiki. There is no example of storing the audio file at the other end of the UDP pipe but apparently you managed this part. This will be raw bytes in the format you specify in the Audio Preferences. Since it works at audio level it can accommodate any audio demod. Note that this is the mixing of all audio going to the same soundcard. If you want to differentiate you have to use Pulseaudio virtual devices (one for each channel). Since you are talking about Virtual Cable I suppose you are running in Windows and I suppose this is something similar.

Brgds, Edouard.

Re: Poor audio with Linux, perfect audio with Windows

Edouard Griffiths
 

Hello,

let me try to recap things... Issue is with transmission right?

So I have a first bunch of questions:
  • Do you encounter the same issues with a CW transmission (either pure CW or in Morse beacon mode)?
  • And when playing a file?
I bet there are no issues and the problem starts when using audio input (mic or line) that is with the microphone icon engaged. Audio input is a bit different because the audio system and the radio system at the other end have different clocks so if there is a synchronization issue you may have this sort of glitches. Normally if this is the case something should show up in the log. However it is up to each plugin to collect audio so proper debug message may be missing.

So I have a few more questions:
  • Which modulator plugin are you using? Only SSB or did you try something else?
  • You are using Pluto, did you try with something else? Possibly the Test Output if you have no other hardware available?
  • What are the details of sample rate: raw device sample rate, interpolation factor?
  • Do you have a frequency shift on the modulator? If this is the case what is the value? (this is to figure out how the interpolation chain is built)

Brgds, Edouard.

Re: Poor audio with Linux, perfect audio with Windows

Boudewijn (Bob) Tenty
 

You can also limit the sample rate. Here I start to get small audio interruptions when set too high on reception,  let say above 4 MS/s. This without touching the priority.

Bob VE3TOK

On 2020-01-15 11:10, Steve (SDRA) 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





-- 

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

Max Planck

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
>
>