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>
> 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
