[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] audio_alsa: problem with "valve" at head of audio
Re: [Discuss-gnuradio] audio_alsa: problem with "valve" at head of audio_alsa sink sub-graph
Fri, 5 Nov 2010 13:55:45 +0100
On Mon, Oct 25, 2010 at 7:43 PM, Marcus D. Leech <address@hidden>
On 10/25/2010 11:25 AM, Almohanad Fayez wrote:
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 it
again. if you look into the "check_topology" method. There's a FIXME
there, what I beleieve is happening, is that when you try to restart
the flowgraph after stopping it GNU Radio is trying to reset your
sound 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. the
flag is "static" just so you can detect your first entry. After that
run make and make install and things should work fine.
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.
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.
|[Prev in Thread]
||[Next in Thread]|
- Re: [Discuss-gnuradio] audio_alsa: problem with "valve" at head of audio_alsa sink sub-graph,
Alexandru Csete <=