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

[Marcus Müller]

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, address@hidden
> > > > 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: address@hidden,address@hidden
> > > > > 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
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio