search

cjcliffe / CubicSDR

Cross-Platform Software-Defined Radio Application
http://www.cubicsdr.com
GNU General Public License v2.0
2.06k stars 254 forks source link

Mac OS X El Capitan strange issues #202

Closed vampjaz closed 8 years ago

vampjaz commented 8 years ago

I have been using CubicSDR for some time on my Mac, using OS X Yosemite. Recently, after updating to El Capitan, I discovered that CubicSDR isn't working properly. Before, the waterfall display had no detectable lag, but now the waterfall is almost useless because of lag. The audio demodulation seems to be unaffected.

EDIT: after experimentation, I found that the waterfall will only animate if I constantly move the mouse.

cjcliffe commented 8 years ago

Just wondering what version is this for? 0.1.4 has some serious issues with waterfall lag in 10.11 and the mouse issue you described that are fixed in 0.1.6+ releases here on GitHub.

Latest SoapySDR release should be stable on El Capitan as I've been testing with it: https://github.com/cjcliffe/CubicSDR/releases/tag/0.1.16-soapysdr

dhoelzer commented 8 years ago

I haven’t messed with Cubic on Capitan, but I can tell you that GnuRadio is less than thrilled… It’s actually the RTL and Osmocom sources that seem to be unhappy. Starting a flowgraph causes a 10-20 second beachball while it figures out the SDR device. Under Yosemite there is zero delay.

On Nov 28, 2015, at 1:28 PM, Charles J. Cliffe notifications@github.com wrote:

Just wondering what version is this for? 0.1.4 has some serious issues with waterfall lag in 10.11 and the mouse issue you described that are fixed in 0.1.6+ releases here on GitHub.

Latest SoapySDR release should be stable on El Capitan as I've been testing with it: https://github.com/cjcliffe/CubicSDR/releases/tag/0.1.16-soapysdr https://github.com/cjcliffe/CubicSDR/releases/tag/0.1.16-soapysdr — Reply to this email directly or view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/202#issuecomment-160327627.

vampjaz commented 8 years ago

I've noticed that too... Rtl_fm is much slower than it used to be

guruofquality commented 8 years ago

I haven’t messed with Cubic on Capitan, but I can tell you that GnuRadio is less than thrilled… It’s actually the RTL and Osmocom sources that seem to be unhappy. Starting a flowgraph causes a 10-20 second beachball while it figures out the SDR device.

Sounds familiar. Recently, a user mentioned the Osmocom source being slow issue. The workaround was to specify the specific device driver in the device arguments parameter. Example "hackrf=0": https://github.com/pothosware/PothosSDR/wiki/GNURadio#grosmosdr-blocks

That probably doesn't explain rtl_fm, but I think the right combination of dependencies for osmocom blocks might cause this. Which might explain one system vs another showing the issue.

dhoelzer commented 8 years ago

Oo, that’s a great tip. I’ll give that a try when I land.

On Nov 28, 2015, at 2:47 PM, Josh Blum <notifications@github.com mailto:notifications@github.com> wrote:

I haven’t messed with Cubic on Capitan, but I can tell you that GnuRadio is less than thrilled… It’s actually the RTL and Osmocom sources that seem to be unhappy. Starting a flowgraph causes a 10-20 second beachball while it figures out the SDR device.

Sounds familiar. Recently, a user mentioned the Osmocom source being slow issue. The workaround was to specify the specific device driver in the device arguments parameter. Example "hackrf=0": https://github.com/pothosware/PothosSDR/wiki/GNURadio#grosmosdr-blocks https://github.com/pothosware/PothosSDR/wiki/GNURadio#grosmosdr-blocks That probably doesn't explain rtl_fm, but I think the right combination of dependencies for osmocom blocks might cause this. Which might explain one system vs another showing the issue.

— Reply to this email directly or view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/202#issuecomment-160331901.

dhoelzer commented 8 years ago

This definitely improves the situation! Thank you!

On Nov 28, 2015, at 2:47 PM, Josh Blum notifications@github.com wrote:

I haven’t messed with Cubic on Capitan, but I can tell you that GnuRadio is less than thrilled… It’s actually the RTL and Osmocom sources that seem to be unhappy. Starting a flowgraph causes a 10-20 second beachball while it figures out the SDR device.

Sounds familiar. Recently, a user mentioned the Osmocom source being slow issue. The workaround was to specify the specific device driver in the device arguments parameter. Example "hackrf=0": https://github.com/pothosware/PothosSDR/wiki/GNURadio#grosmosdr-blocks https://github.com/pothosware/PothosSDR/wiki/GNURadio#grosmosdr-blocks That probably doesn't explain rtl_fm, but I think the right combination of dependencies for osmocom blocks might cause this. Which might explain one system vs another showing the issue.

— Reply to this email directly or view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/202#issuecomment-160331901.

cjcliffe commented 8 years ago

I think this is solved; @red-green 's issues are definitely from earlier builds plus bonus GnuRadio tips :)