Bug #421

gr_prefs in C++ does not work

Added by Alexandru Csete almost 3 years ago. Updated about 1 year ago.

Status:ClosedStart date:05/22/2011
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:gnuradio-core
Target version:release-3.6.4
Resolution:

Description

I was trying to use the new gnuradio-audio wrapper in linux/c++ and I noticed that it always selects ALSA even though my personal settings are set to portaudio. Python and GRC applications correctly use the portaudio backend.

The gr_prefs C++ class seems to use the prefs.py module via some swig magic, which I have very little understanding of, but I could determine that neither the _read_files not the init of the prefs.py are ever called from the C++ application.

I was using Ubuntu 10.10 with swig 1.3.40

History

#1 Updated by Tom Rondeau about 1 year ago

  • Status changed from New to Feedback
  • Target version set to release-3.6.4
  • % Done changed from 0 to 70

Addressing this issue with the branch 'cpp_prefs' published in repo git://github.com/trondeau/gnuradio.git

This duplicates the work done in Python's prefs.py (using the Python ConfigOptions module) but all in C++. It can be used now throughout GNU Radio with no Python at all. This C++ version is SWIG'd so it is also usable in Python.

It was tested to make sure all current preferences were still being read and honored properly. The default gr.prefs now returns a pointer to gr_prefs::singleton function to get the instantiation that way. The Python module still exists and is installed but is not accessed anymore (will be removed completely in next).

The one thing ConfigOptions allows that this version doesn't is the use of both '=' and ':' between the key and value of an option. This C++ version only allows '=' since we use ':' as a separator in some of the options (like 'hw:0,0' for alsa devices) and I didn't want to potentially confuse this.

I will also be adding a way to use environmental variables to supersede the config file preferences. Since all config parameters are listed by "[<section>] <name> = <value>", I propose to make the env variables 'GR_<SECTION>_<NAME>=<value>" for a consistent naming scheme.

#2 Updated by Tom Rondeau about 1 year ago

Suggestion from Corgan to use GR_CONF_<SECTION>_<NAME>=<value> instead to make it explicit that the variable is in reference to a GR configuration parameter.

#3 Updated by Tom Rondeau about 1 year ago

  • % Done changed from 70 to 90

Updated the branch to parse env variables like mentioned above.

#4 Updated by Tom Rondeau about 1 year ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Merged in new fully-functioning gr_prefs class in C++:
f0bcceb462fda30371d83babb254e991f73f237e

#5 Updated by Ben Reynwar about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF