Re: [Discuss-gnuradio] Audio woes

[Marcus D. Leech]

On 08/08/2015 05:26 PM, Marcus D. Leech wrote:

On 08/08/2015 05:20 PM, Marcus Müller wrote:

Hi Marcus,

I do agree on the "Linux audio is fragmented, and neither PA nor ALSA are consistent in documentation and configuration, and that's seriously irritating" aspect.

So, first of all, I always try to circumvent Pulse. Try sysdefault as audio device name (that's the physical device that pulse uses, on FC21/22; I think it was on FC20, already). `aplay -L` might tell you 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 <module>
    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...  :( :(