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