[Speex-dev] Re: just noise
jean-marc.valin at usherbrooke.ca
Tue Apr 24 22:40:56 PDT 2007
> 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
> 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:
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
> 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?
More information about the Speex-dev