Re: [Discuss-gnuradio] Oddities in trunk address@hidden - @8850]

[Eric Blossom]

On Sat, Sep 06, 2008 at 03:20:28AM +0200, Vincenzo Pellegrini wrote:
> Oddities in trunk address@hidden - @8850]
> 
> a few days ago I bought a new host system for my GNURadio development
> activities. Intel E8400 CPU, G35 express chipset.
> 
> All tests with such machine were ok. Reported chipset throughputs were
> 32MB/s etc...
> 
> Then I compiled and ran my Soft-DVB modulator code.
> It built successfully and the application seemed to work all right but the
> signal was not recognized by any of my receivers.
> I actually started blaming any single piece of the HW and tested all of them
> but nothing was wrong.

Vincenzo, 

Are there _any_ warning produced when you compile your code?
If so, make whatever changes are required to make them go away.

What distribution and what version of g++ are you using?
We've found that gcc 4.3 does different optimization than earlier
versions, and code that worked before (but might have unspecified
behavior in some cases) might need some corrections.

> at last I foud the problem to be the revision of the trunk I used.
> 
> More precisely, using Exactly The Same Soft-DVB code on every revision I
> get:
> 
> 1.all revisions provide flawless building and instantiation of Soft-DVB
> application
> 
> 2.all revisions prior to 8800 have soft DVB producing a perfectly receivable
> signal
> 
> 3.all revisions after 8850 have soft DVB producing a totally corrupted
> signal.

Please continue to bisect.  log2(50) is ~6 so it shouldn't take too
long (particularly if you're using ccache).

> currently I'm testing to see what could be the modification responsible for
> this and report that to the list... actually this effort of testing various
> trunk samples taken from the trunk evolution is quite time consuming...
> but I'll report any discovery to this list.
> 
> If  anybody has suggestions... they'd be enormously appreciated
> 
> really thanks
> 
> vincenzo
> 
> PS
> I suspect something that has got to do with syncronization of computed
> output chunks.. but It's just a feeling and, indeed
> quite generic.. :(