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