Re: [Discuss-gnuradio] Unable to find USRP

[Eric Blossom]

On Sun, May 15, 2005 at 10:13:03AM +0930, Berndt Josef Wulf wrote:
> >
> > This is similar to the problem I had with the audio device that doesn't
> > permit it to be opened by two or more processes, see the lines containing
> > EBUSY. I will try to figure out which part of benchmark_usb.py doesn't
> > close the ugen device.
> >
> 
> The problem is that benchmark_usb.py opens usrp.sink() and usrp.source(), 
> both 
> which use the open() calls to access the device. On *BSD this is not possible 
> and is exactly the some problem as seen with the audio.sink() and 
> audio.source() function that I hacked around.
> 
> A possible generic solution to this is to acquire the filedescriptor for the 
> device which is then used by the subsequent calls. e.g.:
> 
> usrp_dev = usrp.open()   <- instantiate device
> sink = usrp.sink(usrp_dev, ....)  <- open source
> source = usrp.source(usrp_dev, .....) <- open sink
> 
> similar for other sink/source devices that are used with GnuRadio.
> 
> Else, *BSD will not be able to run scripts that use sink and source of the 
> same device simultaneously..
> 
> cheerio Berndt

My humble suggestion is that somebody fix the NetBSD libusb
implementation, or if that isn't possible, then fix the usb ugen
device driver.  If what you describe is true, it's totally asinine
that different processes can't open different end points of a given
USB device.  What purpose does such a limitation serve?  Instead of
trying to work around broken code, fix the broken code.

We do expect to be able to open end point 0, the designated usb
control endpoint, by more than one processes.  It's how we configure
the USRP.  The Rx code is smart enough to only mess with Rx related
settings, and likewise for the Tx code.

If the ugen driver has code that forces exclusivity, it ought to be
simple enough to remove it (at least on end point 0).  Search for
EBUSY in the driver source.  It's probably in the first 10 lines of
the open routine.

Eric