[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tony Richardson
Subject: Re: [Discuss-gnuradio] Portaudio Audio Source in Windows
Date: Mon, 9 May 2016 09:56:25 -0500

Thanks Marcus.

I just set the environment variable that you mentioned in the run_gr.bat file that Geof mentioned and portaudio now works.  I realize it is not a clean solution, but it is a working one.  I am happy.


On Mon, May 9, 2016 at 9:42 AM, Marcus Müller <address@hidden> wrote:
Hi Tony,

to be honest, I'll be rewriting GNU Radio's slightly dated and slightly ugly preference system, as it seems, so I'm not 100% giving up on this.
So, I hope the spirit of the workaround was clear to you: you can always manually set this particular setting via python (instead of specifying it in a configuration file).
The python module "detour" was just an attempt to make that a permanent feature of the flow graph. Instead, I could have just asked you to add it pretty far up in the generated top_block.py (or whatever your generated python file is called). There's also another way of specifying such settings – environment variables (which under windows are especially little fun to set...).
You can (as documented in [1]) specify a setting as an environment variable; in your case, something like

GR_CONF_audio_audio_module = portaudio

I know you can configure environment variables somewhere  in windows, but I forget where – my Windows usage is just too rare.

Best regards,

[1] http://gnuradio.org/doc/doxygen/page_prefs.html

On 09.05.2016 14:33, Tony Richardson 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.


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

and close the editor. Basically, you're setting the configuration option manually for the meantime.

Best regards,

On 09.05.2016 04:38, Tony Richardson wrote:
The command:
    gnuradio-config-info --prefsdir --sysconfdir


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     }

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.

Can you execute a

gnuradio-config-info --prefsdir --sysconfdir     

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,

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,

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,

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

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,

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.


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_module= portaudio

Best regards,

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

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]