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

[Tom Rondeau]

On Wed, Feb 26, 2014 at 7:57 AM, Michael Dickens
<address@hidden> wrote:
> Hi Kevin - Thanks for the feedback and related info; it's nice to hear from 
> another GR on OSX user!  I'll push changes to the sink either today or 
> tomorrow for testing. - MLD
>
> On Feb 26, 2014, at 12:33 AM, Kevin Reid <address@hidden> wrote:
>> For the audio source, flowgraph start/stop/reconfiguring and specifying the 
>> device name both work fine as far as I've tested them.
>
> Good!  I'm glad you were able to test these out.  Just because they work for 
> me does not mean they work for everyone :)
>
>> 1) ... or (fewer harmless errors, same effect)
>>    sudo port -f deactivate installed and 'gnuradio*'
>
> Haha!  Even as a MacPorts developer I cannot keep up with "port" CLI usage.  
> I love "sudo port -f deactivate installed and 'gnuradio*'" -- that's so 
> concise yet robust.  Thanks for the info; now, I have to play with these to 
> see what it can do!
>
>> 5) 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).
>
> I intentionally had the user install gnuradio-devel then create a patched 
> version in case things got messed up, for 2 reasons [I should have written 
> these into the original email.]:
>
> a) If things get messed up either building or after copying 
> libgnuradio-audio, you can clean it up by doing
> {{{
> sudo port -f deactivate gnuradio-devel
> sudo port activate gnuradio-devel
> }}}
> and start from go.
>
> b) Sometimes 'port' thinks it is being smart by looking at the available 
> (deactivated) versions of a port, comparing to what is being requested, and 
> then activating a port instead of finishing the install of what you already 
> have being compiled.  Adding in the "-s" (from source) does not always help.  
> Hence, having the user copy the library by hand -- it's not difficult, and 
> it's easy to clean up if things don't work right.
>
>> 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.
>
> I can move these printouts to stderr, even though they are not errors; some 
> are warnings and some just informational.  What do others think: stdout or 
> stderr?

We now have the logging interface in GNU Radio to handle these cases.
I can work off-line with Michael to use this properly. In a gr::block
derived class, it's very simple since a d_logger object already exists
for them. Otherwise, there's some setup that's required.


>> 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!)
>
> Right now, if the specified device (from, e.g., -I or -O) is not found, then 
> it reverts back to the default device.  What you're asking for is for it to 
> instead fail and print out some stuff to stderr, yes?  That's certainly an 
> option.  I'd value other's opinions on this matter.

Typically, the way we handle failures is to fail and exit and not make
assumptions about what the next best option is (this is probably not
universally true within our code, but it's how we try and treat these
situations).


>> 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.
>
> I don't think GNU Radio supports this sort of caller exposure.  I think it 
> can provide "log to file" and "print to terminal", but not communication with 
> non-console-based applications -- as a general rule.  If/when we move 
> completely over to using Qt instead of Wx, then maybe this can be an option; 
> until then, we need to stick with those 2 options.  That said, I'm open to 
> listening to what others have to say on this matter.

Again, we'd use the logger for these things. We inherit from log4cpp
and can configure our logger to use whatever features we get from that
project.

Tom