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