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

[Marcus Müller]

Let me write a short document detailing what /should/ go where first.

Am 10. Mai 2016 03:30:02 MESZ, schrieb Geof Nieboer :
>Yes, Wix is pretty flexible in that regard.
>
>It looks like right now some config files are looking in the $HOME
>directory and some are looking in the $APPDATA directory, so I think we
>should examine thoroughly what is looking where and aim for
>consistency.
>
>Geof
>
>
>On Monday, May 9, 2016, Marcus Müller  wrote:
>
>> Hi Geof,
>>
>> is there a chance to manually specify where the config files go in
>terms
>> environment variables? I.e., tell the installer to put what is in
>> PREFIX/etc into %APPDATA%?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 09.05.2016 17:37, Geof Nieboer wrote:
>>
>> Tony, that's good news.
>>
>> The nice thing is that the environment variables can generally be
>made as
>> relative paths, so I should be able include setting that
>automatically for
>> everyone as part of the msi.  The $home directory is probably the
>best
>> place as Windows doesn't want users changing files in the program
>files
>> directory.
>>
>> Marcus,
>>
>> The way the scripts works is the first you describe, it makes a
>"staged
>> install", during the build process, then Wix comes in and scans
>through
>> that directory to create the installation image, including Python. 
>The key
>> to making that work on the other end is the run_gr.bat file that used
>to
>> set that particular environment prior to running any scripts. It sets
>the
>> python path for instance... All based off the directory that the
>batch file
>> is in ($installer_dir/bin)
>>
>> So any environment variables that gnuradio can use can be set there
>> without impacting ( or being impacted by) the result of the system.
>>
>> Geof
>>
>> On Monday, May 9, 2016, Tony Richardson 
>wrote:
>>
>>> 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.
>>>
>>> Tony
>>>
>>>
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller
>
>>> 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,
 Marcus

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

 Tony


 On Mon, May 9, 2016 at 3:45 AM, Marcus Müller
>
 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, 

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

[Geof Nieboer]

Yes, Wix is pretty flexible in that regard.

It looks like right now some config files are looking in the $HOME
directory and some are looking in the $APPDATA directory, so I think we
should examine thoroughly what is looking where and aim for consistency.

Geof


On Monday, May 9, 2016, Marcus Müller  wrote:

> Hi Geof,
>
> is there a chance to manually specify where the config files go in terms
> environment variables? I.e., tell the installer to put what is in
> PREFIX/etc into %APPDATA%?
>
> Best regards,
> Marcus
>
>
> On 09.05.2016 17:37, Geof Nieboer wrote:
>
> Tony, that's good news.
>
> The nice thing is that the environment variables can generally be made as
> relative paths, so I should be able include setting that automatically for
> everyone as part of the msi.  The $home directory is probably the best
> place as Windows doesn't want users changing files in the program files
> directory.
>
> Marcus,
>
> The way the scripts works is the first you describe, it makes a "staged
> install", during the build process, then Wix comes in and scans through
> that directory to create the installation image, including Python.  The key
> to making that work on the other end is the run_gr.bat file that used to
> set that particular environment prior to running any scripts. It sets the
> python path for instance... All based off the directory that the batch file
> is in ($installer_dir/bin)
>
> So any environment variables that gnuradio can use can be set there
> without impacting ( or being impacted by) the result of the system.
>
> Geof
>
> On Monday, May 9, 2016, Tony Richardson  wrote:
>
>> 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.
>>
>> Tony
>>
>>
>>
>>
>>
>> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller 
>> 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,
>>> Marcus
>>>
>>> [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.
>>>
>>> Tony
>>>
>>>
>>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller 
>>> 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 

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

[Marcus Müller]

Hi Geof,

is there a chance to manually specify where the config files go in terms
environment variables? I.e., tell the installer to put what is in
PREFIX/etc into %APPDATA%?

Best regards,
Marcus


On 09.05.2016 17:37, Geof Nieboer wrote:
> Tony, that's good news.
>
> The nice thing is that the environment variables can generally be made
> as relative paths, so I should be able include setting that
> automatically for everyone as part of the msi.  The $home directory is
> probably the best place as Windows doesn't want users changing files
> in the program files directory.
>
> Marcus,
>
> The way the scripts works is the first you describe, it makes a
> "staged install", during the build process, then Wix comes in and
> scans through that directory to create the installation image,
> including Python.  The key to making that work on the other end is the
> run_gr.bat file that used to set that particular environment prior to
> running any scripts. It sets the python path for instance... All based
> off the directory that the batch file is in ($installer_dir/bin)
>
> So any environment variables that gnuradio can use can be set there
> without impacting ( or being impacted by) the result of the system.  
>
> Geof
>
> On Monday, May 9, 2016, Tony Richardson  > wrote:
>
> 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.
>
> Tony
>
>
>
>
>
> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller
>  > 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,
> Marcus
>
> [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.
>>
>> Tony
>>
>>
>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller
>> > >
>> 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
>> 

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

[Geof Nieboer]

Tony, that's good news.

The nice thing is that the environment variables can generally be made as
relative paths, so I should be able include setting that automatically for
everyone as part of the msi.  The $home directory is probably the best
place as Windows doesn't want users changing files in the program files
directory.

Marcus,

The way the scripts works is the first you describe, it makes a "staged
install", during the build process, then Wix comes in and scans through
that directory to create the installation image, including Python.  The key
to making that work on the other end is the run_gr.bat file that used to
set that particular environment prior to running any scripts. It sets the
python path for instance... All based off the directory that the batch file
is in ($installer_dir/bin)

So any environment variables that gnuradio can use can be set there without
impacting ( or being impacted by) the result of the system.

Geof

On Monday, May 9, 2016, Tony Richardson  wrote:

> 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.
>
> Tony
>
>
>
>
>
> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller  > 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,
>> Marcus
>>
>> [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.
>>
>> Tony
>>
>>
>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller > > 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 

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

[Tony Richardson]

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.

Tony





On Mon, May 9, 2016 at 9:42 AM, Marcus Müller 
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,
> Marcus
>
> [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.
>
> Tony
>
>
> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller 
> 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 

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

[Tony Richardson]

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

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

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

[Marcus Müller]

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

[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.
>
> Tony
>
>
> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller
> > 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 

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

[Geof Nieboer]

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

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

[Tony Richardson]

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

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

[Marcus Müller]

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

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

[Tony Richardson]

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

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

[Marcus Müller]

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. Witasec. 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
>> > 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, 

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

[Marcus Müller]

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

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

[Marcus Müller]

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

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

[Tony Richardson]

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

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

[Marcus Müller]

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

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

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

[Tony Richardson]

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

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

[Marcus Müller]

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