multiple devices in one process?

Jay Salsburg jsalsburg at
Tue Nov 12 21:57:49 UTC 2013

USB 2.0 has a built-in hardware latency. If you are unwilling to go through
the trouble of special coding, be sure to use the USB Dongles alone on their
own PCI USB Card, this will minimize latency.


Hardware may be forced to respond at will if Assembly Code is used to
exercise the interfaces, utilizing acquisition calls controlled by processor
interrupts. A Real Time Clock (RTC) in internal Hardware or an external RTC
can be used to  trigger Processor Interrupts initiating any function in the
(Assembly) code and attached hardware.


Using a patch will not work with any reasonable accuracy, depending on the
Hardware, (an educated guess) of a many microseconds. Patching indicates
high level control (high level language like C++, Python, etc), only low
level control will call the hardware anywhere near the timing desired. If
you are to access two different devices, their data should be both buffered
together in parallel through a first-in-first-out buffer, perhaps even with
the RTC time stamp to quantize the packets therefore allowing subsequent
coherence in post processing. In high speed audio and video interfaces, very
high speed is used, like Firewire and Thunderbolt to stream the data into
memory, eliminating most of the hardware latency you are experiencing. The
maximum acquisition rate for USB 2.0 is about 48,000 samples per second,
times 24 bit depth, times 8, and that is for a fast computer doing nothing
else but recording the data stream.


From: osmocom-sdr-bounces at
[mailto:osmocom-sdr-bounces at] On Behalf Of Michel Pelletier
Sent: Sunday, November 10, 2013 11:14 PM
To: osmocom-sdr at
Subject: multiple devices in one process?


I've been thought-experimenting with capturing data from two devices and
measuring their correlation.  For example, if two rtl-sdr processes are
launched to read one sample block from two devices, how closely do the two
devices' samples line up with each other in time? 

I'm expecting that there will be no reliable correlation.  My working theory
is that each process calls into libusb_handle_events_timeout according to
its own process schedule and that there is no way to coordinate these two
calls to happen closely enough in time for the transfers to happen in a more
synchronized fashion.  Threads do not appear to be any better solution to
the problem.  I'm not an expert in usb transfers, or libusb, or rtlsdr for
that matter, so I'm going only on what I can glean from reading the source
code of librtlsdr.c and libusb documentation.

libusb does say however that it can specifically handle multiple devices in
one async loop.  Multiple bulk transfers can be set up to multiple devices
in one process, and one call to libusb_handle_events_* can be used to handle
those transfers.  My thinking is that because the triggering event for both
samples is now the same function call in the same process, the samples will
be more synchronized, ideally down to some reliably offset of say a few
microseconds. Juha Vierinen's hard-hack to make two devices use a coherent
sample clock makes this idea even more interesting to me.


But, it doesn't look like librtlsdr can handle multiple devices.  I'm game
to take a stab at a patch that can extend its functionality.  But I wanted
to run this idea by the community first before spending code time on
figuring this out.  Do the experts here think that there is any potential
benefit to be gained by taking this approach?




No virus found in this message.
Checked by AVG -
Version: 2013.0.3426 / Virus Database: 3222/6830 - Release Date: 11/12/13

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the osmocom-sdr mailing list