Sounds like you got your issue resolved, Gary? This one was a doozy to
follow, and I'm glad you got it sorted.
And thanks to Marcus for helping sort through it!
Cheers,
Ben
On Mon, May 6, 2019 at 7:17 AM Gary.Simpkins <gary.simpk...@gdscs.co.uk>
wrote:
> Hi Marcus.
>
> It was late last night and I missed the errors in the
> grnradio-config-info -- prefsdir response.
>
> It had the dirs twice. So I changed the Prefix in windows to be just
> GNUradio-3.7, and the tried again.
>
> The prefs now has details includng portaudio.
>
> When I start gnuradio companion I now see lots of warnings about files
> already existing.
>
> When try to generate with the audio source I get a lot of audio config
> lines. all to do with portaudio
>
> BUT ------IT Looks like portaudio is working for me on windows.
>
> Certainly I get two outputs. If they are the I and Q Ioutputs t is my
> next test, but looking very good.
>
> Many Many thanks.
>
> Regards
>
> Gary
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 05/05/2019 17:43, Marcus Müller wrote:
> > 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.simpk...@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.simpk...@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
>
> _______________________________________________
> 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
