[Top][All Lists]

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

Re: [Discuss-gnuradio] [USRP-users] Audio Source configuration

From: Larry Van Der Jagt
Subject: Re: [Discuss-gnuradio] [USRP-users] Audio Source configuration
Date: Tue, 17 Mar 2015 11:31:36 -0400

Thanks for reaching out, all input is appreciated.

The file in use is from files.ettus.com/tutorials/Lab_5.grc.

The "gross" mismatch in sample rates comes about when you set the Rational resampler output rate to be exactly what the UHD:USRP Sink is expecting ... in this case 250K.

The incidence of UUU's is reduced when you introduce the fudge factor suggested at 1.1 in that there is only a short string of approximately 30 U's on startup, but the delay between speaking and transmitting grows from nearly instantaneous at the start of a test to countable numbers of seconds within a short period of time, presumably because there is a buffer involved that is being drained more slowly than it is being filled ....

The OK to Block setting in the Audio Block seems to have no influence (this is as expected since it is noted in the text of the tutorial that ALSA is unaffected by this setting).

Least anyone think that delays on the order of a few seconds are not a problem, I note that in applications intended to improve indoor coverage, delays between the direct path of the outdoor signal and the enhanced path from the regenerative equipment are critical to operation and need to be on the order of 10s of microseconds for the equipment to function correctly.

Any thoughts on how to troubleshoot the Audio Source or determine alternates to ALSA would be much appreciated.

Thanks again, 73


On Tue, Mar 17, 2015 at 10:48 AM, <address@hidden> wrote:

If you're getting long strings of 'U', this means a *gross* sample-rate mis-match somewhere in your flow-graph,
 rather than the more-subtle "two clock" problem.

Make sure that everything agrees internal to the graph about sample-rates, and, perhaps more importantly, that your audio *hardware* is capable of delivering the desired rates.



On 2015-03-17 10:30, Larry Van Der Jagt via USRP-users wrote:

Can anyone point me to some "color" on how to work with the Audio Source.  I am working examples to transmit FM Audio and have problems with Underruns on the UHD:USRP Sink.
The examples (from files.ettus.com/tutorials/Lab_5.grc and others) I am running select Audio Source Arch:alsa and this seems to be a problem.
I have tried to replace the Device name with plughw:0,0 as suggested in the documetnation, but this does not seem to have an impact on the choice of Audio arch: alsa
If I replace the audio source with a signal source at the same sample rate all is well, but the Audio Source implements UUUUUUUUUUUU.
Using the suggestion of having the USRP expect a bit lower rate than the audio can deliver seems to implement nearly limitless delay .... the voice is received but only after a very long ... many seconds delay ... ....
At this time I am using a B210 connected via USB3 to an I7 with plenty of memory running Ubuntu 12.04 ....  I have similar issues trying to use an E310 as the transmitter ...
Any direction would be appreciated.

USRP-users mailing list

reply via email to

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