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