On Sunday 15 May 2005 11:28, Eric Blossom wrote: > 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
Thanks for your help. On inspection of the ugen device driver I can confirm that it implements exclusive access to the control endpoint. After modifying the driver to allow multiple access to the control endpoint benchmarks_usb.py works fine. I'm not familiar with the USB specifications, but from what you're saying did I understand you correctly that multiple access to USB Control Endpoints is permissible, but access to other endpoints are exclusive to one process? If so, we just found a bug in the kernel. In any case, I'm happy to report that, using a modified kernel, the benchmark utility is working now. cheerio Berndt -- Every man who says frankly and fully what he thinks is doing a public service. [Leslie Stephen] _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
