[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] gr-audio OSX fixes test branch
From: |
Kevin Reid |
Subject: |
Re: [Discuss-gnuradio] gr-audio OSX fixes test branch |
Date: |
Tue, 25 Feb 2014 21:33:08 -0800 |
On Feb 25, 2014, at 19:06, Michael Dickens <address@hidden> wrote:
> Another update to <
> https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx >:
...
> If you want do use MacPorts to test out these changes, here's what I
> recommend you do:
Thanks for including the instructions; otherwise I probably wouldn't have
gotten around to testing (as I haven't before).
> 1) make sure the gnuradio-devel port is installed and up to date
> {{{
> sudo port -f deactivate `port installed | grep gnuradio | sed -e
> "s@(active)@@g"`
This can be more robustly written as
sudo port -f deactivate 'gnuradio*'
or (fewer harmless errors, same effect)
sudo port -f deactivate installed and 'gnuradio*'
> 5) install the gr audio library (assuming PREFIX=/opt/local; if not, change
> the "cp" destination):
> {{{
> cd `port work gnuradio-devel`/build/gr-audio/lib
> sudo cp libgnuradio-audio.3.7.3git.dylib /opt/local/lib
> }}}
Mucking with MacPorts prefix files manually is a bad practice; why not just
install the gnuradio built in step 4? (Worked for me -- 'sudo port install -s
gnuradio') Doing this also means you only need to build/install gnuradio-devel
once (rather than installing it before patching it).
> Try different rates, and different I/O devices. You should see printouts
> from "audio_osx_source" and "audio_osx_sink" with information about what it's
> doing.
>
> Let me know what you think! - MLD
For the audio source, flowgraph start/stop/reconfiguring and specifying the
device name both work fine as far as I've tested them.
Some criticism of incidental aspects:
I hope that the final version will not send text to stdout, because this
interferes with a program delivering data to stdout; preferably all log-ish
output should be optional (other components of gnuradio fail at this), and if
present it should go to stderr rather than stdout.
The behavior on not finding the specified device should not be using the
default device; instead, it should fail in a way the caller can observe. Doing
otherwise creates or hides bugs. (For example, suppose I'm building a publicly
accessible receiver (like WebSDR) using a soundcard interface; if it used the
default input device if that device wasn't found, there's a good chance I'd
then be streaming audio from the room the computer is in, which is a privacy
problem!)
Furthermore any information important enough to warn on ought to be exposed to
the caller, not just stderr/stdout, if nothing else so that non-console-based
applications can communicate the information to their actual user interface, as
well as performing appropriate error handling.
--
Kevin Reid <http://switchb.org/kpreid/>