discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Discuss


From: Philip Balister
Subject: Re: [Discuss-gnuradio] Discuss
Date: Mon, 16 Mar 2009 16:05:54 -0400
User-agent: Thunderbird 2.0.0.14 (X11/20080501)

Eric Blossom wrote:
On Sun, Mar 15, 2009 at 02:13:28PM -0700, Johnathan Corgan wrote:
On Sun, Mar 15, 2009 at 1:50 PM, Michael Dickens <address@hidden> wrote:

That said, there is a "libusb-compat-0.1 compatibility layer" for libusb 1.0
... anyone tested this out for various-OS usability?  Reading through the
source code it looks like Linux-only.

< http://libusb.wiki.sourceforge.net/LibusbCompat0.1 > - MLD
From the Wiki however:

"As the compatibility layer implements the exact same ABI and API, no
modifications to existing libusb-0.1-based applications are needed.
You do not even have to recompile them. This compatibility layer is a
drop-in replacement."

So for Linux, anyway, this sounds like good news for us.  Needs testing :)

Johnathan

I might work, but we'll still need to figure out how to fish out the
file descriptor (which is likely to be stored someplace else in the
data structure.)  It would be some much nicer if they just provided an
interface to get it...


In answer to Philip's Q, we fish out a file descriptor that we use
with a linux-specific ioctl, because libusb 0.1 did not provide a way to
submit and reap asynchronous bulk requests.  Without doing it
asynchronously, we couldn't achieve 32MB/s.  I don't know if there is
an interface for this in libusb-1.0.  If there is, we should at least
consider using it.  If not, we should find out the libusb-1.0 way to
fish out the file descriptor and carry on as we have been.

I'm no expert at this stuff, but the story I head is libusb1 is "faster". libusb1 is advertised as having an asynchronous interface, which libusb does not. So maybe there is a way to code libusrp to use the libusb1 interface without directly accessing the file descriptor.

The other approach is to try to extract the file descriptor from libusb-compat.

There is an interesting variable name at line 81:

http://projects.reactivated.net/cgi-bin/gitweb.cgi?p=libusb.git;a=blob;f=libusb/os/linux_usbfs.c;h=ae1aae268007e93069e4ca02b01a60805478f996;hb=34b9eebe35d8167d43cffb6ad6175f6b2251b572

I'm going to see if I can extract this and if it works.

Finally, it looks like you can omit libusb-compat and install libusb-0.1.x with libusb1. I need to see about this also.

Philip

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

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