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 <mailto: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 > <http://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 <mailto: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 >>>> <mailto: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 >>>>> <mailto: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 <http://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 list >>>>>> Discuss-gnuradio@gnu.org >>>>>> <mailto:Discuss-gnuradio@gnu.org> >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> <mailto:Discuss-gnuradio@gnu.org> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>>> >>> >> >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
