Choppy Audio from uhd_rx_nogui on a VM

GNU Radio
1

This is a simple question with a long prelude.

We have a handful of N210/WBX that work great with UHD with which we
are familiar. Until last night, I had not spent more than ten minutes
with GNU Radio. This morning I installed a fresh Fedora-16 guest VM
running on VMware Workstation on a strong Win7-64b host. I used
build-gnuradio to install GNU Radio 3.6.0 . And in twenty minutes with
no issues whatsoever, Im feeding our RF signal generator into a USRP2
and making sane GUI comparisons to our spectrum analyzer. Brilliant!

[shep@fedoraVM1 ~]$ uhd_fft -a addr=10.0.209.194 -f 935M -s 2M
linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2); Boost_104700;
UHD_003.004.002-133-gb61a1103
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes
Using Volk machine: avx_64

I then experimented with the uhd_rx_nogui program and found that the
audio is discontinuous (though almost intelligible), as is shown by
the stream of audio underflow indications that feed to stdout:

[shep@fedoraVM1 ~]$ uhd_rx_nogui -a addr=10.0.209.194 -f 99.5M -m FM
linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2); Boost_104700;
UHD_003.004.002-133-gb61a1103
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes
UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 0.256000 MSps
Actual sample rate: 0.255102 MSps

gr_fir_ccf: using SSE
Using gain: 19.0

gr_fir_ccc: using SSE
gr_fir_fff: using SSE
aUaUaUaUaUaUaUaUaU aUaUaUaUaUOaU

Im uncertain if this is my clueless-ness of audio with the Fedora VM
under VMWare; or something more GNU Radio related. Audio seems work
fine in the VM. And GNU Radio seems to work fine (no errors, good
data) writing files with uhd_rx_cfile. Is this issue likely a VM audio
device issue? Am I off in the weeds running GNU Radio audio on a VM?
This isnt my day job; but any guidance on bisecting this issue is
appreciated.

-Shep

2

On Wed, Jun 6, 2012 at 8:47 AM, Shepard Siegel
[email protected] wrote:

[shep@fedoraVM1 ~]$ uhd_fft -a addr=10.0.209.194 -f 935M -s 2M

gr_fir_ccf: using SSE
This isnt my day job; but any guidance on bisecting this issue is
appreciated.

-Shep

Shep,

I think the problem is a mismatch in sampling rates between what
you’re sending to the audio sink and what the audio sink is expecting.
Notice that there’s the lines that say “Target sample rate” and
“Actual sample rate”. So if you are basing any rate changes on the
target sample rate to get to the audio rate, things are going to be
off a bit and the audio samples are going to be wrong.

The easiest thing to do is just use a blks2.pfb_arb_resampler(rate)
where rate=(target/actual). In reality, you’ll probably want to put
that resampler as close to the audio device as possible so it’s
running at the lowest sample rate that it can.

Tom