On Feb 25, 2014, at 19:06, Michael Dickens <michael.dick...@ettus.com> 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/> _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
