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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
