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

Reply via email to