I have created a new top level component called gr-audio. The goal of
gr-audio is to combine all supported audio architectures under a single
source and sink block.
Gnuradio has 6 different top level components, each for a different
audio architecture. If you used audio in python, this was transparent,
as the python file was test-importing each possible architecture. But if
you used audio in c++, you would have to hard-code a specific audio
architecture into your code.
gr-audio presents one interface to the user in both c++ and python. At
build-time, all architectures available to the compiler are built into
the library. At runtime, an available audio architecture is selected.
This selection is based on default priority, or if present, a
configuration file setting.
The build system will continue to configure and build the old top-level
components; so this will not break C++ that was coded for a specific
audio component. Anyone using audio block in python will be
automatically calling into the new component.
On Thu, Mar 10, 2011 at 2:00 AM, Marcus D. Leech [email protected]
wrote:
audio architecture. If you used audio in python, this was transparent,
The build system will continue to configure and build the old top-level
Thanks,
-Josh
I’d like to be the first to start the tin-foil-hat brigade and posit that there
exists more than one
Josh B… It’s the only explanation for the apparently-inhuman level of
productivity we’ve
come to associate with the object known as Josh B…
Off to put my tinfoil hat on
I don’t know how many of them there are, but the one who posted this
can read my mind. I was thinking about exactly this problem wrt.
creating a Funcube Dongle block that would encapsulate both audio and
control interface. Thank you.
On Thu, Mar 10, 2011 at 07:39, Alexandru C. [email protected] wrote:
I don’t know how many of them there are, but the one who posted this
can read my mind. I was thinking about exactly this problem wrt.
creating a Funcube Dongle block that would encapsulate both audio and
control interface. Thank you.
I was about to comment the same. Aside from making your fcd work
easier, Josh’s work will let us finally start adding some pure C++ GNU
Radio examples that use audio, such as the venerable dial_tone app.
(It has been possible to write GNU Radio applications and hierarchical
blocks in pure C++, without any Python, since the 3.2 release series.)
Once gr-audio gets some further testing, then is merged into the next
branch, we can immediately port the gnuradio-examples/python/audio
scripts to individual C++ apps in gnuradio-examples/c++/audio.
I was able to test 4 of the 6 architectures. Testers for the osx and
windows audio support would be appreciated.
Thanks,
-Josh
I’d like to be the first to start the tin-foil-hat brigade and posit
that there exists more than one
Josh B… It’s the only explanation for the apparently-inhuman
level of productivity we’ve
come to associate with the object known as Josh B…
Off to put my tinfoil hat on
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
where several users had problems installing UHD after thy installed
gnu-radio (the only fix was reinstalling everything including the OS). I
have GNU-radio up and running but dont have UHD. What is the recommended
action?
where several users had problems installing UHD after thy installed gnu-radio
(the only fix was reinstalling everything including the OS). I have GNU-radio
up and running but dont have UHD. What is the recommended action?
You don’t have to re-install the Operating System (if that’s what you
mean).
If you installed GR from sources, install UHD and then re-run the make
process for GNU Radio starting at ./configure, and see if it finds the
libs.
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
From: Marcus D. Leech [email protected]
Subject: Re: [Discuss-gnuradio] installing UHD after gnu-radio
To: [email protected]
Date: Thursday, March 10, 2011, 2:16 PM
On 03/10/2011 02:06 PM, Martin B. wrote:
You don’t have to re-install the Operating System (if that’s what you
mean).
If you installed GR from sources, install UHD and then re-run the make
process for GNU Radio starting at ./configure, and see if it finds the
libs.
MB
Martin:
Don’t forget that gr-uhd support only made it into the master recently
(like in the last couple of days),
so a GIT image from before that won’t have gr-uhd support in it, so
they’ll have to fetch a fresh
GIT image with the gr-uhd support in it.
On Thu, Mar 10, 2011 at 11:16, Marcus D. Leech [email protected]
wrote:
Don’t forget that gr-uhd support only made it into the master recently (like
in the last couple of days),
Just to be clear, the ‘master’ branch does not yet contain gr-uhd;
that will only happen once we merge ‘next’ back into it. I recently
posted about the process that will be followed, but it won’t happen
until the ‘next’ branch has a little more work completed on it.
You don’t have to re-install the Operating System (if that’s what you
mean).
If you installed GR from sources, install UHD and then re-run the make
process for GNU Radio starting at ./configure, and see if it finds the
libs.
MB
Martin:
Don’t forget that gr-uhd support only made it into the master recently
(like in the last couple of days),
so a GIT image from before that won’t have gr-uhd support in it, so
they’ll have to fetch a fresh
GIT image with the gr-uhd support in it.
I have created a new top level component called gr-audio. The goal of
gr-audio is to combine all supported audio architectures under a single
source and sink block.
[snip…]
At runtime, an available audio architecture is selected.
This selection is based on default priority, or if present, a
configuration file setting.
Is there any way to specify in the code (e.g., through a command-line
option) which audio device to use?
This selection is based on default priority, or if present, a
configuration file setting.
Is there any way to specify in the code (e.g., through a command-line
option) which audio device to use?
There isnt, but, it would be conceivable to have an api call to set the
preferred architecture. Have you found a need for one?
(To be clear, I want to specify the architecture (alsa, portaudio,
windows, etc.), not the device name.)
For my applications, I have used
from gnuradio import audio_portaudio as audio
to get good results from any system I run them on, including the
temporary Cygwin and MinGW installations I use for testing. For
testing, it would be nice to be able to specify the architecture
to test on the command line of the test program.
With the new code, my only choice is to specify the architecture
in a file in my home directory, which is different for each
temporary installation Cygwin or MinGW. Also, it appears that I
can only set a preference and have no way of telling whether I am
actually using the architecture I asked for.
Could we have optional arguments to audio.{source,sink} to specify
the architecture (default=“auto”) and whether the specified
architecture is required or only preferred?
As an aside, I have never known where to find the documentation
for the configuration (or is it preferences?) file(s) (yes, I found
the info for gr-audio in the README file). Maybe we need a FAQ
entry telling about config.conf, common options, and what to search
for in the code for the less common options.
(To be clear, I want to specify the architecture (alsa, portaudio,
windows, etc.), not the device name.)
Aha, my first guess.
architecture is required or only preferred?
maybe we need a 4th parameter “required_architecture” to the
constructor
or some static class methods like set_required_architecture(arch), and
get_available_architectures()
just a thought
As an aside, I have never known where to find the documentation
for the configuration (or is it preferences?) file(s) (yes, I found
the info for gr-audio in the README file). Maybe we need a FAQ
entry telling about config.conf, common options, and what to search for
in the code for the less common options.
like a wiki page for standard gnuradio configuration options?
(liking this idea)
Is there any way to specify in the code (e.g., through a command-line
option) which audio device to use?
Maybe I read that wrong… 2nd attempt:
In the audio constructor, the second parameter is a string called
“device_name”. Its depends on the implementation whether this has any
meaning. Alsa for example will use this.
to get good results from any system I run them on, including the
or some static class methods like set_required_architecture(arch), and
get_available_architectures()
just a thought
I agree with the idea of being able to specify the subsystem (alsa, oss,
portaudio, osx, windows, jack, etc.) in the constructor. Obviously, it
should gracefully fail if you ask for an unsupported arch.
-Josh
I definitely agree with the wiki page idea. Perhaps just add to a README
the
website address so there’s some local clue as to how to get the
information.
Thanks!
Tom
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
