On 08/08/2015 05:26 PM, Marcus D. Leech wrote:
things I can’t 
Yeah, tried sysdefault, tried playing with what aplay -L told me. All
the same. Massive Ua underruns and sound that isn’t even close to
resembling what
I’m trying to do.
It’s frustrating because both system sounds and Firefox sound are
working perfectly fine.
Some follow-up.
Things got a bit better when I did a:
sudo yum -y install alsa-*
In that I could now use hw:X,Y specs and some of the time, it would
work, but a lot of the time it would raise an exception:
Using Volk machine: avx_64_mmx_orc
INFO: Audio sink arch: alsa
ERROR: [hw:0,0]: snd_pcm_sw_params: Invalid argument
Traceback (most recent call last):
File “./multi_chan_pulsar.py”, line 471, in
tb.start()
File
“/usr/local/lib64/python2.7/site-packages/gnuradio/gr/top_block.py”,
line 109, in start
top_block_start_unlocked(self._impl, max_noutput_items)
File
“/usr/local/lib64/python2.7/site-packages/gnuradio/gr/runtime_swig.py”,
line 5607, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: audio_alsa_sink
Now, if you simply restarted the application a lot of times, it would
occasionally “catch”, and it would run normally, without issue.
So, I tried a smaller simpler app, using the same audio-sink
parameters. It does the same as above, except less frequently than
the larger app.
My suspicion is either a timing issue, or we have a memory stomper that
is more likely to manifest in a larger flow-graph, and with timing and
perhaps ASLR, you occasionally “sneak through”, and don’t provoke an
“Invalid Argument” error way down deep in audio_alsa.
Sometimes with my larger flow-graph, I’d make a random change to it,
like changing the taps on a filter a bit, and that would cause it to
start working
again slightly more frequently. Sure smells like a memory
stomper… 
