[Speex-dev] Re: just noise

[Jean-Marc Valin]

> OK I finally figured out the second noise problem.  It's a riddle
> wrapped in a mystery inside an enigma.  Judging by the somewhat odd
> structure of le_short() and be_short(), I think this keeps coming up
> over and over again.  Even Apple's byte swapping macros fail under
> certain circumstances, and here's why:

Funny thing is you seem to be the first to report that... not quite sure
why.

> 1. Logical shifting must be used, not arithmetic (or else the high bit
> is wrong)

So far so good.

> 2. Conversion from short to float must be signed, not unsigned (or else
> the line level is wrong)

Seems like there was a problem there and I ended up with a +32768 offset
-- not good.

> 3. The order of operations must be written just-so, or gcc stumbles over
> the conversion from short to float

what do you mean here?

> The offending line was this one:
> 
> for (i=0;i<FRAME_SIZE;i++)
>     input[i] = le_short( in[i] );
> 
> This always fails with the current le_short() function.  Here are
> updated versions, in both macro and inline form.  You can leave inline
> off of the function version and it still works fine:

<snip>

I'll fix that for the next release (hopefully soon).

> Now I am sorry to rant a moment, but I am getting too old for this
> stuff.  Whenever I am speaking with fellow programmers, they love to
> jump to the conclusion that the problem is mine and that there is
> nothing wrong with the code.  I am experienced enough to know that there
> are multitudes of reasons why things fail and that yes, even vanilla
> code examples often fail.  I tried your sample code and it didn't work,
> plain and simple.

Well, it didn't work on big-endian machines and I happen not to have any
such machine, which is why I rely on bug reports for these
architectures. As for which code to blame, my experience with Speex is
that 95% of the problems are with code using Speex and not with the
Speex code (I'm not going into the reason why code is broken).

> UNIX is like this through and through.  Whenever I try something, I just
> know it won't work, like I knew this wouldn't work.  The fault is almost
> never mine (at least not through incompetence, because I follow
> directions explicitly), but is cause by assumptions about the
> infrastructure by myself and others.  For all its benefits, the unix
> mindset can easily condemn us to a life of servitude, baby sitting our
> computers instead of getting real work done.

I guess you could always switch to this Windows OS people keep talking
about. I've never really used it, but everyone keeps saying lots of nice
things about it ;-)

> Anyway, I hope this series of emails shows the importance of providing
> full examples for the target environments.  If you ever want speex to
> catch on in the mainstream, everyday people need to be able to drop it
> in, but at this point only hackers can really do that.  I mean the kind
> of hackers willing to spend 2 days to fix 2 lines of code that should
> "just work."

All I can say is "shit happens" (and endianness bugs too). However, most
people who know what they're doing (e.g. don't attempt to pass u-law
instead of floats to get 4x the compression) usually get Speex working
rather quickly.

> So I thank you from the bottom of my heart for making such a brilliant
> piece of software as speex, I really appreciate what you guys stand for
> :)  I just hope that you get some time to step back and polish up the
> sample code and manual just a hair.  I know how it goes when you have to
> spend all of your time on development to keep something even just
> working, so this rant is not directed at anyone in particular :)

What kind of polish to the sample code. Can you send a patch?

	Jean-Marc