Re: [Discuss-gnuradio] wfm_rcv.py works, but with half-second delay in audio!

[Eric Blossom]

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