Cvs+svn updates / audio / config files

Hi Folks,

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 protected]:/sources/gnuradio co
gr-build

Then

$ 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

~/.gnuradio/config.conf

[audio]

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

[audio_alsa]

default_input_device = hw:0,0
default_output_device = hw:0,0

period_time = 0.010 # in seconds
nperiods = 4 # total buffering = period_time *
nperiods
verbose = false

[audio_jack]

default_input_device = gr_source
default_output_device = gr_sink

[audio_oss]

default_input_device = /dev/dsp
default_output_device = /dev/dsp

latency = 0.005 # in seconds

[audio_portaudio]

#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]
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]
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.
They accept:

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.

Thanks!
Eric

Hi Eric,

I tried the new scripts today. Updating of my old distribution with
cvs up didn’t work. It had some problems with the parallel to serial
scripts which were removed and didn’t want to compile. Thus, I did a
fresh checkout of everything and the build worked flawlessly. This was
on my debian box. Next, I will try it on Mac OS X to see if it works
there too.

Thomas

On Fri, Mar 31, 2006 at 05:30:04PM -0800, Thomas S. wrote:

Hi Eric,

I tried the new scripts today. Updating of my old distribution with
cvs up didn’t work. It had some problems with the parallel to serial
scripts which were removed and didn’t want to compile. Thus, I did a
fresh checkout of everything and the build worked flawlessly. This was
on my debian box. Next, I will try it on Mac OS X to see if it works
there too.

Thomas

Thanks for the feedback.

The problem with parallel to serial is an out-of-date set of
dependencies for swig. It’s possible to work around that by

$ cd gnuradio-core/src/lib/swig
$ rm gnuradio_swig_python.d
$ touch gnuradio_swig_python.d

But I think the fresh checkout is a better bet.

Eric

audio_portaudio implementation pays attention to ok_to_block. All
others treat it as if it were True.

gr-audio-osx also takes and uses the “ok_to_block” parameter (as a
bool C++ type), with default TRUE for either source or sink.

Eric B. wrote:

On Fri, Mar 31, 2006 at 05:30:04PM -0800, Thomas S. wrote:

Hi Eric,

I tried the new scripts today. Updating of my old distribution with
cvs up didn’t work. It had some problems with the parallel to serial

–snip –

$ touch gnuradio_swig_python.d

But I think the fresh checkout is a better bet.

I agree with the latter. It really did take too much work on too many
directories (primarily audio) to get the build to work and on my three
remaining computers running gr, I did a delete and reinstall. That was
less time and less work.

Bob


AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as
charged!