discuss-gnuradio
[Top][All Lists]
Advanced

[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: Wed, 26 Feb 2014 08:09:26 -0800

On Feb 26, 2014, at 4:57, Michael Dickens <address@hidden> wrote:

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

No, if it's going to fail in a way the caller can detect and handle, then 
printing is irrelevant and undesirable (unmodular).

GNU Radio is a library as well as a framework. As a library, it should 
(ideally) permit complete control over its inputs and outputs by the code which 
invokes it.

I see Tom Rondeau wrote that current GR has a logging facility; that's an 
appropriate thing to use here (if the logging can't be redirected or 
suppressed, then that's no longer “your” 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.
> 
> 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.

I think I've managed to confuse the issue by combining discussion of printing 
with discussion of error handling. I do ***NOT*** want GNU Radio to go putting 
up GUI dialogs or anything like that -- in my particular use case (the GR 
process is also a web server) that would by equally or more useless than 
printing to console. What matters is that the *caller* is able to perform error 
handling.

As a user of GNU Radio from Python, this is what I want to write:

try:
    self.source = gnuradio.audio.source(device_name='foo')
except KeyError:  # or whatever fits 'device not found'
    # do application-specific error handling

This is preferable, but I get the impression that failing in block constructors 
is problematic, based on comments in gr-osmosdr; it would also be acceptable if 
there's a way to find out afterward (gr-osmosdr provides one sort of 
accidentally):

self.source = gnuradio.audio.source(device_name='foo')
if not self.source.get_valid():
    # do application-specific error handling

This would also allow you to provide fallback behavior such as a source of 0s 
at the requested sample rate, which might be a desirable default in some 
applications (e.g. a transceiver with no microphone device falls back to being 
a receiver).


Both of these are examples of exposing success/failure _to the caller of the 
constructor_ which can then handle it in an appropriate way. This is the only 
thing that I am arguing is critical. Whether logging occurs in addition to this 
is a separate issue.

(Note that there are also, of course, non-OSX audio sinks/sources; I don't know 
how they signal failure to the caller but it should be made the same on all 
platforms. If there's an existing failure-signaling path for non-OSX then we 
should just use that everywhere.)

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]