Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Marcus Müller]

Hi Geof,

as I'm currently thinking about how we'd want GNU Radio to actually behave when looking for config files, I'd like to ask you a question regarding generation of the installer:

How do you do it? Are you letting CMake install everything in a "clean slate prefix", and then just package that up and ship it as an .msi, or is there some magic CMake install() hooks that actually do "note down" what should get installed where?

Point is that what we have as global configuration under under Unixes usually ends up in  {prefix, if any}/etc/gnuradio/conf.d, but on windows, there only seems to be %appdata% – which looks like it would be different between different versions of windows. Hence my question is how I could tell an installer (your installer?) where to put configuration files.

Best regards, and thanks for all the work!

Marcus

On 09.05.2016 16:06, Geof Nieboer 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio