There have been a lot of updates in CVS and a few in svn over the last
few days. Yes, I know that that having some of the stuff in CVS and
some in subversion is a pain. Consider it an experiment that will
converge to a single solution as soon as we think it’s safe.
Part 1: working with CVS and subversions
First, if you’ve still got a usrp CVS checkout around, please remove
it. It’s out of date. FYI, sourceforge is down again…
To manually checkout the current usrp code use this command:
$ svn co http://usrp.svnrepository.com/svn/usrp/trunk usrp
Note the location of the space at the end of the line. You will end up
with a subdirectory called “usrp” that contains the current (trunk)
usrp code. This is equivalent to CVS HEAD. The svn repository
contains fixes that aren’t in the last stuff in CVS on sourceforge, so
updating is highly recommended.
However, to make life easier for you and me, I’ve also updated the
tools in gr-build to handle most of the problems with having stuff in
two different systems.
If you’ve already got a gr-build checkout, just do an update:
$ cd …/gr-build
$ cvs -q up
You’ll get new versions of checkout, for-all-dirs, README and two new
commands: up and status.
If you’re starting from scratch (probably a good idea),
$ cvs -d :pserver:email@example.com:/sources/gnuradio co
$ cd gr-build
$ ./checkout -x mc4020 -x comedi -x radar [-x portaudio]
will get the “regular stuff”
Building is the same as before:
$ ./for-all-dirs …/buildit [-n]
Once you’ve got a tree checked out under gr-build, you can see what’s
been updated in the repositories without changing anything by:
$ ./for-all-dirs …/status
To update to the latest stuff use:
$ ./for-all-dirs …/up
These commands issue the proper cvs or svn commands depending on the
directory they’re run in.
The for-all-dirs command now accepts two mutually exclusive
options, -c and -s, that restrict the directory traversal to cvs or
svn directories respectively.
Part 2: configuration files and audio / portaudio
We now have a way to set user preferences using windows “ini” style
files. At this point the preferences all have to do with audio, but
that’ll probably change over time. The system defaults are stored
in files under PREFIX/etc/gnuradio/conf.d. You can override them on a
per-user basis by creating a file called ~/.gnuradio/config.conf
These are the current options and default values:
This file contains system wide configuration data for GNU Radio.
You may override any setting here on a per-user basis by editing
specify which audio module to load, or use “auto” to have the system
select one. Valid choices depend on your OS and which modules
you’ve installed, but typically include: auto, audio_alsa,
audio_oss, audio_portaudio, audio_jack, audio_windows
audio_module = auto
default_input_device = hw:0,0
default_output_device = hw:0,0
period_time = 0.010 # in seconds
nperiods = 4 # total buffering = period_time *
verbose = false
default_input_device = gr_source
default_output_device = gr_sink
default_input_device = /dev/dsp
default_output_device = /dev/dsp
latency = 0.005 # in seconds
#default_input_device = hw:0,0
#default_output_device = hw:0,0
verbose = false
The items you’re most likely to want to mess with are the audio module
that’s imported when you do “from gnuradio import audio” and
audio module specific default values for the input and output devices.
The system default:
audio_module = auto
means it works like it used to: we try importing audio modules until we
find one that loads. If you want to force a choice, e.g. portaudio,
then edit ~/.gnuradio/config.conf so that it reads:
audio_module = audio_portaudio
Likewise, there’s a separate section for each audio module that allows
you to specify the default input and output devices to use. These are
used if the device_name argument passed to audio.sink(…) is missing or
All audio module source and sink constructors are now homologous.
audio.sink(sample_rate, device_name, ok_to_block),
audio.source(sample_rate, device_name, ok_to_block),
where device_name and ok_to_block are optional and default to “” and
True respectively. ok_to_block should be False when there’s another
source or sink in the flow graph that’s really setting the pacing
through the pipeline. Note that at this time, only the
audio_portaudio implementation pays attention to ok_to_block. All
others treat it as if it were True.
Part 3: GNU Radio 2.7
I’m planning on making new tarballs for everything in the next day or
so. If you’re the kind of person that tracks cvs+svn, please update
everything and let me know of any problems.
I’ll generate tarballs as soon as I get some feedback on the current
changes. Everything is currently passing “make distcheck”, so I
don’t expect any hangups.