Re: [Discuss-gnuradio] gr-audio OSX fixes test branch

[Kevin Reid]

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/>