GNU Radio, One Step at a Time

Hi Gary,    
This confuses simple folk like me.  
  this confuses simple folks such as me, too!    That --prefsdir output is most defintely bogus. I can speculate what  happened there, however:    
Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d  
  That --prefsdir value is part of the source code that gets compiled  into the tool/the GNU Radio libraries. Normally, you wouldn't do that,  "hardwiring" a directory path into a library, but write it in a  configuration file or something.    However, in this case, that's the place we start looking into to find  the configuration files. So, that's the one thing that actually need to  hardwire.    So, there's a text string "Z:\gr-build\src-  stage3\staged_install\Release\etc\gnuradio\conf.d" in there, which is  probably a remnant of the machine that your GNU Radio got built on  (again, how did you install that?).  Sadly, the "\" gets interpreted by the compiler to be "escape symbol",  so that you can have things like "\n" for newline in strings. Luckily,  none of the first letters of directory names combined with "\" give a  valid escape sequence, so the compiler just silently drops the "\" and  this is the string you end up with.    I'll admit it: that's funky, and I didn't know that happened. We'll  most definitely will have to rewrite something to make this work under  windows (which uses backslashes for directory separation, unlike  unixoids, which use forward slashes).    So, why does --userprefsdir work, but --prefsdir not?     Well, --userprefsdir is built from environment variables at runtime, so  it's correct, not mangled by a compiler.    I hear you say, that's fine and all, and now?     Welllllll! I thought it strange that, although your userprefsdir seems  correct, GNU Radio didn't read the configuration file you modified. So,  down the rabbit hole it goes. Here's our culprit, in prefs.cc:      std::vector<std::string>    prefs::_sys_prefs_filenames()    {      std::vector<std::string> fnames;        fs::path dir = prefsdir();      if(!fs::is_directory(dir))        return fnames; //<------------------------OUCH!     […]        // Find if there is a ~/.gnuradio/config.conf file and add this to      // the end of the file list to override any preferences in the      // installed path config files.      fs::path userconf = fs::path(gr::userconf_path()) / "config.conf";      if(fs::exists(userconf)) {        fnames.push_back(userconf.string());      }        return fnames;    }    So what happens here is that if the prefsdir isn't a proper directory,  and Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d bloody  well excels at not being a proper directory, it just throws the towel  and doesn't try to scan the userprefsdir things for configuration  files.    I'm fully away of the irony saying the following in a > 10 emails  thread that started with a sound card problem:    The solution should be simple.    There's a way of overriding the hardwired prefsdir! We don't even have  to set it to the *right* directory, just any path that is actually a  directory. The way to do that would be setting an environment variable  "GR_PREFIX" that leads to the right place.    So, I don't actually know where these things get installed to on  Windows, or on your individual machine, but: Can you look for a  directory "conf.d" in a path ending in etc\gnuradio\conf.d?    Let's say it's C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d .    then, you'd have to do something like    set GR_PREFIX=C:\Programs\gnuradio\dragonsbehere  gnuradio-config-info --prefsdir    If that now prints  C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d, we're almost  there. Try, from the same command window,     gnuradio-config-info --prefs    Does that work?  If it does, there's a way to permanently set environment variables  under windows, but I've forgotten it. I can look it up, if you want.    Best regards,  Marcus    On Sun, 2019-05-05 at 13:55 +0100, Gary.Simpkins wrote:  
Hi Marcus    --prefsdir returns    Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d    I dont have a drive Z:    This confuses simple folk like me.  Willing to learn though.    Regards    Gary    On 05/05/2019 11:30, Marcus Müller wrote:  
Hi Gary,    The "* " is good; when you take that full output of gnuradio-  config…,  and replace the ";" with line breaks, you get a nice list with  indented  subentries. In this case, the list entry of interest would be    gr-audio  * portaudio  * windows    Nothing to do with windows vs UNIX, it's just the way we output  things  (for historical reasons). I think it wasn't originally meant to be  all  on one line (I don't actually know), but you can't change a  "diagnostic" program's output to look better later on – there might  be  someone else's software depending on it being one line (welcome to  the  hell of popular software!).    
I saved and restarted the PC, but GNUradio is not using  portaudio. So  it  
Huh! Interesting, to say the least. Can you check whether  `gnuradio-  config-info --prefs` actually shows the correct value (as put by  you  there)?    Best regards,  Marcus    On Sun, 2019-05-05 at 10:39 +0100, Gary.Simpkins wrote:  
Hi Marcus and any windows experts    Trying to get portaudio working in GNURadio (win10). can you  answer  these simple questions.    Using  gnuradio-config-info  --enabled-components, I get the  following.    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.       Is the * infront of portaudio significant?  Is it a wild card?  do  you  now what this means? (I know this is windows and not UNIX)    gnuradio-config-info  --userprefsdir  responds with    C:\Users\Gary\AppData\Roaming\.gnuradio    In this directory is a config.conf file.  It was empty, so I  added    [audio]    audio_module = portaudio    I saved and restarted the PC, but GNUradio is not using  portaudio. So  it  looks like it is not being used.    Regards    Gary        On 04/05/2019 14:39, Müller, Marcus (CEL) wrote:  
Hey Gary,  please keep things on the list! Good news:  That's the exact opposite of what I wanted to convey! *Use* GNU  Radio's  existing portaudio interface; chances are that your GNU Radio  installation supports that (which is why I asked how you've  installed  it).  https://www.gnuradio.org/doc/doxygen/page_audio.html tells us  how  to do  that:  you just need to find your GNU Radio configuration (for me as  Unix  user  it's in ~/.gnuradio/config.conf, but yours is probably  somewhere  else;  running `gnuradio-config-info --userprefsdir` should give you  an  idea  where to look). Add, if not already in there, the following:    [audio]  audio_module = portaudio    Done! That tells GNU Radio to not just try the first best guess  of  what  audio system you want to use (that being windows API under  windows),  but to specifically use portaudio – and that should have the  features  you're looking for.    Still, the windows source not working as it should is a pain.  We  should  fix that.    Best regards,  Marcus    On Sat, 2019-05-04 at 08:05 +0100, gary.simpkins@gdscs.co.uk  wrote:  
Many thanks for the explanation. Looks like I can go no  further.  I do  not have the skills to develope the audio source.    Gary    Sent from my Huawei Mobile      -------- Original Message --------  Subject: Re: [Discuss-gnuradio] Audio source cannot use 2  outputs  (Stereo) in  windows  From: "M黮ler, Marcus (CEL)"  To: discuss-gnuradio@gnu.org,gary.simpkins@gdscs.co.uk  CC:      
Hi Gary!    
I have double checked and all the windows audio devices I  have  used  for the audio source are 2 channels.  
I never doubted that – all I wanted to point out that the I  think  it  was Windows that told the GNU Radio windows audio source it  saw  only  one channel, and consequently the windows audio source only  enabled  one  output port.    I was wrong, it turns out! When you look at gr-  audio/liob/windows/windows_source.cc, you'll find the  number of  output  streams of the block to be hardcoded to be between 1 and 1,  so...  1:      windows_source::windows_source(int sampling_freq,  const std::string  device_name)  : sync_block("audio_windows_source",  io_signature::make(0, 0, 0),  io_signature::make(1, 1,  sizeof(float))),    The last line does that.  So, that's a um, underdeveloped feature in the windows  audio  source.    
They work fine with WSJT-X, or MAP65.    The stereo channels I wish to use are the I and Q outputs  from  
my  
SDRPLay Duo using virtual cables    (I have tried the speaker outputs from the PC with  GNURadio  audio  source  and get the same problem)    Does the audio source work with two channels on linux?  
Yes, (haven't tried today, but it /used/ to work), but it  sadly  shares  nearly no code with the windows audio source. That's due to  fact  that  Linux' ALSA and Windows' sound API and OS X's Core Audio  are  pretty  different.    I do have an idea, though, which *might* be a solution to  your  problem,  but: untested; don't expect wonders.    Has your GNU Radio build portaudio enabled? As said, it's  not  tested,  but unlike the windows audio source, the portaudio source  at  least  from  the state of the source code (far as I can tell) enables as  many  maximum output streams as your card has.  
I am using the latest version of GNURadio 3.7.13.4 on a  64bit  win  
10  
PC.    
Built from source, or where did you happen across it?    
I am really stuck here. Nothing I try allows the second  output to  
be  
enabled.    
Sorry to hear that! We'll try to get you unstuck :)    Best regards,  Marcus  
_______________________________________________  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  

GNU Radio, One Step at a Time

Sunday, May 5, 2019

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

No comments:

Post a Comment