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