I got it built and running, and now I have run into this problem:
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
OERROR: [default]: Device or resource busy
OOOOOOOOOOOOOOOOOOOOOOTraceback (most recent call last):
File “/home/rsharpe/wireshark/top_block.py”, line 148, in
tb = top_block()
File “/home/rsharpe/wireshark/top_block.py”, line 80, in init
self.audio_sink_0 = audio.sink(48000, “”, True)
File
“/home/rsharpe/target/lib64/python2.7/site-packages/gnuradio/audio/audio_swig.py”,
line 122, in make
return _audio_swig.sink_make(*args, **kwargs)
RuntimeError: audio_alsa_sink
OOOOO
Principal Investigator
Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
If you can, try installing pulseaudio. Then use the device name “pulse”
for
the audio device. Pulse sits on top of ALSA (generally) and helps with
distribution of the audio resources.
Just because you’ve asked the audio sink to set a rate of 48k, doesn’t
mean the rest of the flow-graph agrees with that decision. It also
doesn’t
necessarily mean that the audio hardware supports a 48k rate
(although, most do).
If you’re getting audio overrun (as opposed to under-run), it
generally means that you’re sending samples to the hardware faster than
they
can actually be processed by the hardware.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Sat, Sep 6, 2014 at 4:34 PM, Marcus D. Leech [email protected]
wrote:
that laptop and will have to move to another machine.
most do).
If you’re getting audio overrun (as opposed to under-run), it generally
means that you’re sending samples to the hardware faster than they
can actually be processed by the hardware.
I looked through the flow graph, which I had copied from Mike Ossman’s
first lesson on using the HackRF One, and indeed I had a problem. I
had the wrong value for the decimation field of the Rational
Resampler.
I had also changed the sample rate because I thought that the sample
rate was too high.