Issues with rtl_tcp
scott at scottcutler.net
Thu Sep 27 07:35:39 UTC 2012
And another followup:
A locally-built version of rtlsdr.dll works perfectly, and only takes a
few tens of milliseconds for either rtlsdr_set_sample_rate or
The binaries I am comparing against were built on 9/13 and are from this
I looked through the Git commit log for the past month but didn't see
anything that seemed relevant.
Does anyone know the precise way in which these binaries were built? It
would seem very odd if some build setting caused the difference, but
that's my only idea at the moment.
On 9/27/2012 12:05 AM, Scott Cutler wrote:
> It appears that both of my problems are nearly the same: the "worker
> cond timeout" happens because the first thing my program does is set
> the sample rate, which takes a whopping 2.58 seconds. This apparently
> delays rtlsdr_callback long enough that the timeout in
> pthread_cond_timedwait is hit, causing tcp_worker to bail.
> rtlsdr_set_center_freq takes 1.09 seconds and is unrelated to the
> select call--that comes down immediately. It is something to do with
> the rtlsdr library itself (or one of its dependencies). Time to
> investigate more deeply.
> On 9/26/2012 4:26 AM, Simeon Miteff wrote:
>> Hi Scott
>> On 09/26/12 12:35, Scott Cutler wrote:
>>> Slight correction/clarification to the below: obviously, I am not
>>> calling rtlsdr_set_center_freq when using rtl_tcp.exe. Instead, what I
>>> see is that I can queue up a bunch of tuning calls, but they only kick
>>> in at a very slow rate (1 hz). The effect is similar to when I used
>>> native libs, where rtlsdr_set_center_freq also took 1 s on the main
>> I experienced the same maximum 1 hz tuning rate with rtl_tcp.
>> A quick look at the code shows a select() call in the command_worker
>> thread with a timeout set to 1s, but that doesn't explain the observed
>> behavior, because, as I understand select(), it should return as soon as
>> the UDP socket has data available (the timeout is used to allow the
>> thread to terminate when rtl_tcp shuts down). Nevertheless, my spidey
>> sense tells me this is the place to look...
More information about the osmocom-sdr