Re: [Svxlink-devel] SVXLINK Improvements
Brought to you by:
sm0svx
From: Tobias B. <sm...@us...> - 2008-05-22 17:51:57
|
Hi again Steve, I'll answer this again since I was in a hurry getting to work this morning when I answered it the last time. The info in my previous mail still holds though. On Thursday 22 May 2008 09:36:33 st...@ar... wrote: > It seems that the LinkSys NSLU2 uses an Intel IXP420 processor, which > dos not implement a floating point co-processor. I do not understand why > SVXLINK then uses floating point that extensively, since it has to be > provided through emulation, and this is VVVEEERRRYYY SSSLLLOOOWWW. Even though I would really like SvxLink to run on the NSLU2 I'm not ready to sacrifice the simplicity and beauty of using floats in the audio pipe concept. I have proved previously that SvxLink actually will run a SvxLink node on the NSLU2 at about 50% CPU usage as I remember it. I'll actually be quite happy if it only can run a remote receiver. Maybe it will manage that at 16kHz with floats. I don't know. The main target platform will always be a rather standard (low end) x86 PC. > Thinking about this, I should rather implement the new DTMF stuff using > finxed point arithmetic only. The same applies to the > interpolator/Decimator/ ToneDetector/ToneGenerator. This is not too > complicated, when the remaining floating point values are normalized within > a -1...+1 range. > A far better way would be the use of 32bit fixed point samples internally. You can't trust the sample values to be within the -1..+1 range. That's the whole idea of using floats. If you just clip it, you will get distorsion. The limiter/clipper combination at the end of the RX audio processing chain is used to constrain the float samples to -1..+1 but no signal detectors/decoders should be placed after that stage. That audio is only meant for a human ear. Another reason for using floats is that many signal processing libraries use floats (or double), like spandsp and fftw. 73's de SM0SVX / Tobias |