[Top][All Lists]

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

[Discuss-gnuradio] USB Issues

From: Michael Dickens
Subject: [Discuss-gnuradio] USB Issues
Date: Sat, 14 Jan 2006 13:55:50 -0500

[I sent a similar this out just under 1 week ago, and have received no replies ... so I'm sending this updated message in hopes that someone will share their thoughts on how to proceed. - MLD]

I've tried all the USB / general coding speed tweaks that I can think of and easily find / work out, all to no avail. I'm getting about 28 MBytes/s on my Mac at home (Dual G4 @ 1.25 GHz, 1.75 GB DRAM @ 167 MHz, cheapo PCI USB 2.0 card); and 17-19 MBps on our lab Mac (Dual G5 @ 2 GHz, 1 GB DRAM @ 1 GHz, with built-in USB 2.0).

I believe that the primary MacOS throughput issue is an added Apple- provided application-layer library/API called "CoreFoundation" which provides "ease of use" to the application writer. The next layer of USB I/O transport is Darwin's "ports", which are part of the mach kernel but can be somewhat accessed by the application layer. Going to the "ports" directly would definitely speed throughput up, but Apple's documentation doesn't give enough info on how to write the programs, and I can find no examples of such programming. Most of what I can find is via Apple's Darwin Source Code repository < http:// darwinsource.opendarwin.org/ >, reading through the source code to figure out how to do things. I really shouldn't have to go to this level to "just" get async USB to work!

If I can't use "ports" directly, then I can do that via a kernel extension (KEXT), or "device driver" in older terms. The primary issue blocking me investigating this option is that GR's use of LIBUSB would need to be changed so that all USB calls go through the FUSB code (which in turn could call LIBUSB or not as needed). Various initialization routines (e.g. usb_init(), usb_find_busses () ) would be moved to the KEXT, requiring new code in FUSB to access those KEXT routines. Right now those routines are "hard coded" to use LIBUSB (most are in usrp/host/lib/usrp_prims.cc ).

Thus, IMHO what needs to happen is to route -all- USB calls through FUSB, so that there is 1 place to deal with "everything USB". Thoughts? - MLD

reply via email to

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