Thanks Marcus. I just set the environment variable that you mentioned in the run_gr.bat file that Geof mentioned and portaudio now works. I realize it is not a clean solution, but it is a working one. I am happy.
Tony On Mon, May 9, 2016 at 9:42 AM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hi Tony, > > to be honest, I'll be rewriting GNU Radio's slightly dated and slightly > ugly preference system, as it seems, so I'm not 100% giving up on this. > So, I hope the spirit of the workaround was clear to you: you can always > manually set this particular setting via python (instead of specifying it > in a configuration file). > The python module "detour" was just an attempt to make that a permanent > feature of the flow graph. Instead, I could have just asked you to add it > pretty far up in the generated top_block.py (or whatever your generated > python file is called). There's also another way of specifying such > settings – environment variables (which under windows are especially little > fun to set...). > You can (as documented in [1]) specify a setting as an environment > variable; in your case, something like > > GR_CONF_audio_audio_module = portaudio > > I know you can configure environment variables *somewhere *in windows, > but I forget where – my Windows usage is just too rare. > > Best regards, > Marcus > > [1] http://gnuradio.org/doc/doxygen/page_prefs.html > > > On 09.05.2016 14:33, Tony Richardson wrote: > > There appear to be some problems with "python module"s in Windows GRC > too. I get an error that the editor can't find a particular file. If I > add the python block in GRC, then have it generate code and add the code to > the corresponding Python file from an external editor - I can then run the > top level Python file from a command prompt and it works! (Appears to be > using portaudio). > > If I try to execute from GRC it replaces my Python source with a file > containing the line: > > # this module will be imported in the into your flowgraph > > and will not run anymore. > > Thanks for your help, but I agree that it is time to give up. > > Tony > > > On Mon, May 9, 2016 at 3:45 AM, Marcus Müller <marcus.muel...@ettus.com> > wrote: > >> Hi Tony, >> >> > The lack of path separators is troubling. >> >> I couldn't agree more. But since that just means that the separator get's >> "eaten" somewhere, and we don't know whether that happens when generating >> these paths or just when printing, I'm still full of hope… >> >> The fact these directories don't exist on my machine (even with >> appropriate separators) is more troubling. >> >> … my hopes being crushed. >> >> > Is there a way to override the default values? >> >> Yes, but not at runtime, I'm afraid: The "first" directory a program >> looks into for configuration has to be hard-coded somewhere, and in the >> case of GNU Radio, it's specified via the GR_PREFSDIR CMake Variable when >> building GNU Radio. >> That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where >> CMake expands the @GR_PREFSDIR@ macro. The actual setting of that >> variable happens in the main gnuradio/CMakeLists.txt, line 165 >> >> set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH >> "System configuration directory" FORCE) >> >> so we learn that CMAKE_INSTALL_PREFIX was set to >> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D >> >> So that's essentially where I'd have to give up: That code was put there >> during build, and I can't change it later. >> >> What I'll probably do is a bug report about GNU Radio, upon finding the >> prefsdir path not to be a directory (in your case: not to exist at all) >> giving up and not even trying to read any other paths. I might fix that by >> allowing users to specify these directories as environment variables; that >> would make sense to me, but as it kind of changes "logical" API, I'd like >> to discuss this with a maintainer. >> >> I think I might come up with a workaround, however. Again, I haven't >> tried this, especially not under windows, where the whole "launch an editor >> and edit that file" aspect might fail, but *shrug*: >> >> In your GRC flow graph, add a "python module". >> There, without indenting, add the following code >> >> from gnuradio import gr >> p = gr.prefs() >> p.set_string("audio","audio_module","portaudio") >> >> and close the editor. Basically, you're setting the configuration option >> manually for the meantime. >> >> Best regards, >> Marcus >> >> >> On 09.05.2016 04:38, Tony Richardson wrote: >> >> The command: >> >> gnuradio-config-info --prefsdir --sysconfdir >> >> returns >> >> C:gr-buildsrc-stage3staged_installReleaseetc >> C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d >> >> The lack of path separators is troubling. The fact these directories >> don't exist on my machine (even with appropriate separators) is more >> troubling. I assume this is why config files in the installed etc >> directory are not being read. After using the Windows installer, I have >> what appear to be corresponding directories here: >> >> C:\Program Files\GNURadio-3.7\etc >> C:\Program Files\GNURadio-3.7\etc\gnuradio\conf.d >> >> I have a HOME environment variable defined in Windows, so I think GRC is >> looking in $HOME/.gnuradio for a config.conf file. Running GRC actually >> creates a $HOME/.gnuradio directory and places some configuration files in >> that directory, but doesn't appear to read from it. I also tried putting a >> config.conf file in the APPDATA/.gnuradio directory but it isn't being read >> either. >> >> Is there a way to override the default values? >> >> Tony Richardson >> >> On Sat, May 7, 2016 at 9:05 AM, Marcus Müller < >> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote: >> >>> Sooo gnuradio-runtime/lib/prefs.cc: >>> >>> 77 // Find if there is a ~/.gnuradio/config.conf file and add this to >>> 78 // the end of the file list to override any preferences in the >>> 79 // installed path config files. >>> 80 fs::path homedir = fs::path(gr::appdata_path()); >>> 81 homedir = homedir/".gnuradio/config.conf"; >>> 82 if(fs::exists(homedir)) { >>> 83 fnames.push_back(homedir.string()); >>> 84 } >>> 85 >>> >>> >>> This means that things in Users/youruser/Application >>> Data/.gnuradio/config.conf *should* be read. >>> >>> I also tried changing the canvas size in the "c:/Program >>> Files/GNURadio-3.7/etc/gnuradio/conf.d/grc.conf" file, which I think is >>> supposed to be the system-wide file, but changes there have no effect >>> either. >>> >>> Uh-oh. >>> >>> Can you execute a >>> >>> gnuradio-config-info --prefsdir --sysconfdir >>> >>> please? >>> >>> Back to topic: >>> >>> Is there a way for me to figure out what configuration files are being >>> read? >>> >>> >>> I'm really not experienced Windows debugger; under Unixes, I'd do run >>> like (to trace all "stat" calls, ie. when the code above checks for the >>> existence of config.conf) >>> >>> strace -e stat -o '|grep config.conf' gnuradio-config-info -v >>> >>> >>> but I really don't know whether that even works in theory under Windows. >>> >>> I'm a bit worried about this line: >>> >>> 81 homedir = homedir/".gnuradio/config.conf"; >>> >>> Because it implicitly assumes that the OS considers "/" as path >>> separator between .gnuradio and config.conf. Boost might or might not fix >>> that under windows. But it's probably OK. >>> >>> Best regards, >>> Marcus >>> >>> >>> On 07.05.2016 15:41, Marcus Müller wrote: >>> >>> The * is actually just an artifact of how that list is generated; it's >>> written by CMake when gathering the enabled audio engines; When running >>> cmake, you'll see something like >>> >>> -- ###################################################### >>> -- # Gnuradio enabled components >>> -- ###################################################### >>> -- * python-support >>> -- * testing-support >>> [..] >>> -- * gr-atsc >>> -- * gr-audio >>> -- * * alsa >>> -- * * oss >>> -- * * portaudio >>> -- * gr-channels >>> [...] >>> >>> >>> And our beautiful hack to make alsa, oss, portaudio ... look like bullet >>> points under gr-audio is actually to get these the name "* alsa", "* oss" >>> and so on :D. That doesn't break automatic "grep-ability" to let scripts >>> check for any of these, and if you had something like >>> >>> gnuradio-config-info --enabled-components|sed s'/;/\n/g' >>> >>> it'd give you the "original" tree-ish looking structure. >>> >>> so, for now, that's totally ok. >>> >>> Is there a way for me to figure out what configuration files are being >>> read? >>> >>> Hm, logging. Waaaaitasec. I'll have to look this up; will do later. >>> >>> Best regards, >>> Marcus >>> >>> >>> On 06.05.2016 14:55, Tony Richardson wrote: >>> >>> I think I'm making progress with your help Marcus. >>> >>> The output of "gnuradio-config-info --enabled-components" is: >>> >>> python-support;testing-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;* >>> portaudio;* >>> windows;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq >>> >>> What does the '*' before portaudio mean? >>> >>> I think you are also correct in that it appears my config.conf file is >>> not being read. GRC created a ~/.gnuradio directory and populated it with >>> a grc.conf file and prefs directory. I created a config.conf file in the >>> same directory. Adding the [grc] stanza seems to have no effect. I also >>> tried changing the canvas size in the "c:/Program >>> Files/GNURadio-3.7/etc/gnuradio/conf.d/grc.conf" file, which I think is >>> supposed to be the system-wide file, but changes there have no effect >>> either. Is there a way for me to figure out what configuration files are >>> being read? >>> >>> Tony Richardson >>> >>> >>> >>> >>> On Fri, May 6, 2016 at 3:14 AM, Marcus Müller < >>> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote: >>> >>>> Huh, can you verify portaudio is in the output of "gnuradio-config-info >>>> --enabled-components" ? >>>> >>>> Can you add another section, >>>> >>>> >>>> [audio_portaudio] >>>> verbose = true >>>> >>>> Just to verify: you're using the "[..]" section headers correctly, and >>>> the rest of the conf file looks ungarbled, right? >>>> >>>> We might be encountering a case where the config file simply isn't >>>> read; as a quick test: >>>> Close all gnuradio-companions, add >>>> >>>> [grc] >>>> canvas_default_size = 100,100 >>>> >>>> to that file, and open up the companion – your canvas size should now >>>> be 100x100px. Is that the case? >>>> >>>> Best regards, >>>> Marcus >>>> >>>> >>>> On 06.05.2016 00:20, Tony Richardson wrote: >>>> >>>> Thanks, but I've tried that (setting "audio_module = portaudio"). It >>>> doesn't appear to have the desired effect. >>>> >>>> Tony >>>> >>>> On Thu, May 5, 2016 at 4:26 PM, Marcus Müller < >>>> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote: >>>> >>>>> Sorry, not currently running any Windows VM, but in the spirit of >>>>> giving you the info you need as fast as possible: >>>>> >>>>> Quick lecture of the audio sink/source factory tells me that under >>>>> windows, by default the windows audio architecture is used. >>>>> So to use portaudio instead, you need to have a GNU Radio config file >>>>> (under unixoids, that's ~/.gnuradio/config.conf), and add >>>>> >>>>> [audio] >>>>> audio_module= portaudio >>>>> >>>>> >>>>> Best regards, >>>>> Marcus >>>>> >>>>> On 05.05.2016 22:59, Tony Richardson wrote: >>>>> >>>>> I'm using the pre-built Win64 binary of GNURadio listed on the >>>>> gnuradio.org site. The portaudio library was included as part of the >>>>> Win64 build, but I can't seem to figure out how to use it instead of the >>>>> default windows audio. (I want an audio source and the windows audio >>>>> source does not work.) I've tried putting "audio_module = portaudio" (and >>>>> "audio_module = audio_portaudio") in the config.conf file, but when I run >>>>> a >>>>> simple flowgraph that includes an audio source and sink, I see: >>>>> >>>>> INFO: Audio source arch: windows >>>>> INFO: Audio sink arch: windows >>>>> >>>>> in the console and there is no sound. I assume the lines above are >>>>> telling me that the windows audio devices are being used and not the >>>>> desired portaudio devices. I have tried leaving the device name in the >>>>> audio source blank as well as trying "0" and "hw:0,0", but still see the >>>>> messages above. Can someone tell me how to configure audio for portaudio >>>>> or is it just not supported? >>>>> >>>>> Tony Richardson >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing >>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> <Discuss-gnuradio@gnu.org>Discuss-gnuradio@gnu.org >>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
