On Mon, Mar 07, 2005 at 04:40:33PM -0800, John Gilmore wrote:
I finally got a SMA cable to hook the USRP to my old 4937 tuner.
wfm_rcv.py worked like a charm on the first try, tuning a strong local
FM radio station. I cabled the computer's audio output into my main
amplifier, which also has a traditional FM tuner. When I switched
between the tuner and the computer audio output, I noticed that the
computer output was about half a second delayed from the FM radio
signal available thru an ordinary tuner.
Any explanations?
John
PS: I'm using the tarball release from the Debian packages, not the CVS.
These are the prime suspects in decreasing order of estimated importance:
(1) We currently enable the the audio sink/source and usrp
sink/source to begin xfering data when they are instantiated.
I think a better solution is to enable them all at once when the
flow_graph start() method is invoked. That is, they would be
configured when they were instantiated, but we'd defer actually
enabling data xfers until everything was ready to go. There's a
lot of one-time setup that happens between the time the first
block is instantiated and the time we're really ready to run the
C++ scheduler. (GUI setup, all the connects, checking of input
and output matching, allocating buffers, etc)
(2) The USRP host library is currently using 8MB worth of buffering.
This combined with (1) allows lots of data to build up in the
library buffers before we start running the C++ scheduler.
(3) We currently don't implement any kind of explicit audio queue
management. We only block when the OS buffer is full or empty.
There will be differences between the sample clocks in the USRP
(or any other hardware for that matter) and the audio cards. We
need a means to insert or delete samples as needed to harmonize
the rates.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
