discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: address@hidden
Subject: Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows
Date: Wed, 08 May 2019 01:19:06 +0100

Yes all sorted. What I wanted to do was simple. To have two stereo actually IQ inputs and a single 4 channel output Now I have MAP65 working with adaptive phasing using the SDRPlay Uno software with and RSP Duo SDR.
Brilliant. Portaudio solved the problem. Marcus stuck with me to get it working. I am really grateful.
Gary

Sent from my Huawei Mobile


-------- Original Message --------
Subject: Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows
From: Ben Hilburn
To: "Gary.Simpkins"
CC: Marcus M黮ler ,GNURadio Discussion List


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 <address@hidden> 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, 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]