Audio woes

I have a Xeon server system with a SB X-Fi USB sound module on it.
Changed configuration so that system sounds play on it, etc.

Youtube works just fine.

But any GR app that tries to use it gets massive underruns, regardless
of the sample rate I use–I’ve tried 48K, 32K, 8K, 44.1K, 96K. The
pulse
audio daemon appears to be configured for 44.1K as its natural rate.
And as I said, system sounds and Firefox have no problem with audio
output at all.

This is F20. What do I need to know? [As an aside, I hate Linux
audio. It’s the most fragmented and frustrating piece of Linux, and I’m
a total
Linux fanboy, but I hate sound configuration, and the “brand-new
sound architecture of the week”].

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 :wink:

Other than that: might be systematic[1]. Did I mention I /really
like[2]/ how Ubuntu doesn’t try to bring people to discuss problems with
the upstream developers?

Best regards,
Marcus

[1] https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1051665
[2] very much, it makes my head hurt, how much I like Ubuntu.

On 08/08/2015 05:20 PM, Marcus M. 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 :wink:
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.

On 08/08/2015 10:15 PM, Marcus D. Leech wrote:

FC21/22; I think it was on FC20, already). aplay -L might tell you
Things got a bit better when I did a:
Traceback (most recent call last):
RuntimeError: audio_alsa_sink
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… :frowning: :frowning:

More information. On my laptop, running exactly the same F20 load, with
all the same updates applied, same version of UHD, Gnu Radio, and
friends,
the audio sink comes up every time, whether I’m using the on-board
audio hardware, or any of my USB audio dongles. So now, I don’t know
what
to think. My lappy is an i5, the “troublesome” system is a Xeon E3.

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

things I can’t :wink:
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… :frowning: :frowning:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs