This isn't a tool issue, it was where I was storing the tools. The path to the recording directory in my case was too long (windows limit). Because of path length it seems to block the saving of the file. It may be something completely different for you though, I'm just sharing my experience.causeway74,
Okeee thank you for advice and you found out,
i dont like these programs in the main root map/directory, but i will try your advice to put the recording log in to root.
I also dont understand what a long install path have to do with fact the audio is not working. For last 25 years iam using PC, never have this issue before (btw i do lots of MiDi music with Terra bytes music files using long path )
Are you positive that it's a path length issue? How do you know it's not something else, like spaces in the path name?I also dont understand what a long install path have to do with fact the audio is not working. For last 25 years iam using PC, never have this issue before (btw i do lots of MiDi music with Terra bytes music files using long path )
Did you know this?
Why the audio record log file need to be in root?
Why is this not in the manual?
For me, CPU is 5-13% and Memory is at 71000KHowdy all
Have you seen this before?
I seem to not get it on the v1.0.14 release with its related plugins, once I go to v1.0.15+ it starts doing this.
Best I can describe is that SDR# "pauses" for a second. As can be seen from the screen grab at that point CPU spikes and then returns to the normal sub 10% for SDR#. Look at the Diagram and the SDRSharp.exe
This of course has an effect on the decode and voice output.
Disabling the plugin (Demodulator) in SDR# has no effect, even stopping the SDR dongle in SDR# has no effect. The processing remains the same.
Only option is to close SDR# and rerun. On the specific signal I have a SNR of around 34 and 100% Receive in the Demodulator, except when it jumps to a new frequency where I see a slight drop to high 80%\low 90%.
I have been running v1.0.14 now for a few days without this issue. Previously when testing with v1.0.15 versions it would happen, within minutes\hours\max within a day.
I have tried a clean install of SDR# and then upgrading directly to the latest TTT release with the same results. Have also tried SDR# version 1660 and 1700.
Not sure.... Was wondering if it might be due to some of the background components. VC Redist? .NET? maybe?
Visible tab is default and always on "Calls" if I'm understanding the question correctly.What is the visible tab in 'Network Info'?
What options you using in the plug-in?
Do you have checked in SDR# > Radio > 'Correct IQ'. If yes, try with it disabled. On occasions I see high CPU usage with this on.
SDR#1700 with SDRPlay RSP1a ==> if you know a driver, iam able to test it for you.Anyone running SDRPlay RSP1a on TTT/TNM and see a big improvement compared to the RTL SDR v3?
Thanks, yes I read that RSP's were only supported up to a specific older version of SDR# and then no longer.SDR#1700 with SDRPlay RSP1a ==> if you know a driver, iam able to test it for you.
Yep, and in older SDR# 14xx serie the TTT plugin not working.Thanks, yes I read that RSP's were only supported up to a specific older version of SDR# and then no longer.
In my response number #1,056 i answered your questionWas just wondering if there is much improvement using a RSP or Airspy Mini VS the RTL SDR v3. Is it really worth the extra $ when looking at digital decoding, etc.