Thanks Geof. A Windows audio source would be great. Just to be clear
though, because I started down this path by first trying to get GRC to
process my config.conf file. I never succeeded. Is this a known problem?
Tony
On Mon, May 9, 2016 at 9:06 AM, Geof Nieboer <gnieb...@corpcomm.net> wrote:
> Tony,
>
> Getting the Windows audio source to work is on my "to do" list. I
> reworked the sink already, so I don't think it will be difficult to do the
> source either.
>
> The hard coded paths are troublesome, as using a Windows installer
> that allows users to install in any path they desire after everything has
> already been compiled is fundamentally incompatible with hardcoded paths at
> compile time. One potential way to implement Marcus's suggestion might be
> to incorporate it into the run_gr.bat file that sets the gnu radio
> environment prior to running the python script.
>
> As you probably already surmised, the directories referenced that you
> saw are exactly where the build scripts originally built gnuradio prior to
> packing it into an .msi.
>
> Geof
>
>
> On Monday, May 9, 2016, Tony Richardson <richardson.t...@gmail.com> 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>
>> 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
>>>> > 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> 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
