Eric Blossom wrote: > > > Nothing ;-) > Seriously, we don't mess with any kind of desktop installation, etc. > > Is it busted all the time, or only when a gnu radio app is running? > > I think we may have a problem playing nicely with the sound daemon > under Gnome, but that should only occur if some of our code is > running. The symptom is that our code blocks forever in the open for > the audio source or sink. >
I'll have to take another poke, I guess. This has happened since I installed gnuradio (or perhaps wxPython--they were done at the same time). It doesn't seem to matter whether I'm actively running a gnuradio app or not. In other matters, I managed to get dbs_debug.py running, after changing the config on libfftw3--as you suggested. The dbs_debug app always returns "could not lock" when changing frequency on the DBS daughterboard--my supposition is that the frequency-setter isn't waiting long enough for the "PLL locked" bit to come back before concluding that it isn't locked. On a fast CPU, the PLL could take (relatively) and *eternity* to indicate lock. Also, in dbs_debug, I found that keeping the scope_sink window around caused the application GUI to lock up as soon as the scope_sink window showed anything, so I took it out, leaving only the FFT display. Now, if I can only find my SMA-to-other-stuff collection, I'll get the DBS_RX hooked up to a feedhorn, and see if I can see the GPS L1 signal :-) !!! -- Marcus Leech Mail: Dept 1A12, M/S: 04352P16 Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Advanced Technology Research Nortel Networks [EMAIL PROTECTED] _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
