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@example.com:/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
on 2006-04-01 00:24
on 2006-04-01 05:32
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 2006-04-01 06:05
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
on 2006-04-01 08:46
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!
on 2006-05-03 21:00
> 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.