In my application I have a sub-graph that terminates an an audio_alsa
sink.
At the “head” of this sub-graph, I’ve placed a valve, so that I can turn
off data being
copied to the audio_alsa sink.
When this valve transitions from “closed” (data flowing) to “open” (data
not flowing), it provokes
the following error in audio_alsa_sink:
audio_alsa_sink[plughw:0,0]: snd_pcm_hw_params failed: File descriptor
in bad state
terminate called after throwing an instance of ‘std::runtime_error’
what(): check topology failed on audio_alsa_sink(1) using ninputs=1,
noutputs
Am I being an idiot here? Should this work? If not, why not?
Further, there’s a “OK to block” parameter for an audio_alsa_sink. What
does it do?
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Marcus, this is a problem with the
gnuradio/gr-audio-alsa/src/audio_alsa_source.cc. I ran into a few weeks
ago and i managed to find a quick and dirty fix for.
I’m assuming that you’re stopping the flow graph and restarting itagain.
if you look into the “check_topology” method. There’s a FIXMEthere,
what I beleieve is happening, is that when you try to restartthe
flowgraph after stopping it GNU Radio is trying to reset yoursound card
and it thinks that it’s in a corrupt state.
My fix was to add a “static bool” variable that skips
the"snd_pcm_hw_params(d_pcm_handle, d_hw_params);" function call.
theflag is “static” just so you can detect your first entry. After
thatrun make and make install and things should work fine.
al
On 10/25/2010 11:25 AM, Almohanad F. wrote:
My fix was to add a “static bool” variable that skips the
“snd_pcm_hw_params(d_pcm_handle, d_hw_params);” function call. the
flag is “static” just so you can detect your first entry. After that
run make and make install and things should work fine.
al
I’m not actually stopping/restarting the flow-graph. I’m simply opening
a ‘valve’ block that’s
at the head of the sub-graph that feeds the audio sink. I’ll look at
the "check_topology’
method as you suggest, though.
This happens as soon as I “open” (stop data flow) the valve block.
On Mon, Oct 25, 2010 at 7:43 PM, Marcus D. Leech [email protected]
wrote:
it’s in a corrupt state.
‘valve’ block that’s
at the head of the sub-graph that feeds the audio sink. I’ll look at
the "check_topology’
method as you suggest, though.
This happens as soon as I “open” (stop data flow) the valve block.
I have also started to encounter this problem, both when using a
Selector
block in GRC or when performing lock/reconfigure/unlock in python code.
The
trick with the static bool conditional works well for me. Thanks for the
tip.
Alex