[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] UHD Underrun with Wav File Source and USRP Sink

From: Josh Blum
Subject: Re: [Discuss-gnuradio] UHD Underrun with Wav File Source and USRP Sink
Date: Mon, 12 Nov 2012 13:03:21 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

On 11/11/2012 01:21 PM, Tom Hendrick wrote:
> Hello all,
> I am using a USRP1 and an LFTX daughtercard and Ubuntu 12.04.
> I am having an issue with a simple GRC script I made which has three
> blocks. A WAV file source connects to a resampler block and then to
> the UHD USRP sink.
> When I run the script I get a single underun right at the start of
> running the script and no other underrun. When I run the script using
> the sudo in front of it, I get two underruns right at the start of
> running the script and no other underrun. I monitored the signal out
> of the LFTX using an oscilloscope and noticed some blips/noise when
> the script is run and I believe they correspond to the underruns.  I
> tried this with and without real-time scheduling enabled and didn't
> see any difference.
> I tried the same exact type of script with an older version of GRC on
> a different laptop with Ubuntu 10.04.  This uses the USRP sink block
> not the UHD sink block.  This script plays the file perfectly without
> any underruns at all and I don't see the blips/noise at the beginning
> of the signal.
> I am using the LFTX for an audio application and the blips/noise will
> cause a problem for me.  Does anyone know why I am seeing this
> behavior with the newer UHD block?  Is there anything I can do to
> eliminate it?

Hi Tom,

If I am understanding correctly, you are getting some initial underflows
when the flow graph begins processing. This is causing some
discontinuous stream interruption over on the receiver side.

If thats the case, I dont know of anything specifically to cause this,
so it might just be the issue of interrupt coalescing. That is the host
isnt initially ramped up to push out USB packets at full speed. So,
driver wise, there may have been a subtle difference thats brining this
out, USB 1.0 vs .1 for example.

I'd like to replicate it over on end. But if I have a quick suggestion,
it may be helpful to zero-pad the beginning of the wavefile so those
initial discontinuities are only lost in the padding.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]