Re: [Discuss-gnuradio] Why FM doesn't sound good

['Eric Blossom']

On Thu, Dec 27, 2001 at 03:00:49PM -0800, Ettus, Matt wrote:
> Under OSS and kernel drivers, many soundcards will allow you to set whatever
> rate you want, and they report back that its been accepted, but then just
> use the nearest rate anyway.  Many are designed for the 11.05, 22.1, 44.1
> kHz sequence, and only approximate the 48 kHz sequence (or vice versa) , yet
> report that they support the exact rates.  For most audio its ok since you
> can't hear the difference.  It causes over or underruns for us.  ALSA
> drivers will tell you the exact rates available, including the numerator and
> denominator of the dividers in the chip.

Thanks for the info.

> The ideal setup is to have all codecs clocked from a common source, but no
> consumer and few professional cards allow that.
> 
> > Is the adjacent channel noise because the default windowed FIR doesn't
> > have steep enough skirts?  As I recall, the Q of the windowed filter
> > (normalized narrowness of pass band) is linear with number of taps.
> > I.e., twice as many taps ==> twice as narrow of pass band.  We ought
> > to be able to get a narrower pass band (if reqd) by increasing the
> > number of taps (with concommitant increase in mips).
> 
>       The adjacent channel noise is aliased in because the filter is too
> wide in frequency.  If you go up to 150 samples long (which is about all my
> machine can handle), its better.  When you use a 75 tap filter with a 125
> decimation ratio, you don't even use 50 out of each 125 samples, and thus
> you are throwing away signal and aliasing in noise. 
>
>       The 160ksamples/sec IQ rate gives you a maximum of 160 kHz of BW.
> FM signals are really at least 200kHz wide, so you are losing the peaks of
> the signal.  You are also aliasing the signal's own energy back on itself.
> 
>       Lastly, the window functions have very slow transition bands, so if
> you make them narrow enough to cut out adjacent channels, they will
> significantly attenuate the signal's high frequency components.  They are
> better suited for the case where you would be decimating down to 160
> ksamples per sec complex for a signal which is 50 to 100 kHz wide, and would
> have a better filter in the next stage.

OK.  I've got some (non-free) filter design software.  I don't see why
we can't cook up some specific, higher performing filters that we can
use instead of the existing windowed design.  It requires refactoring
VrComplexFIRFilter, but I think that that's a good idea anyway.

>       Is there any reason why they chose to use VrComplex instead of
> standard complex templates?  It would be nice to have complex shorts.  It
> fits better with the AD card and with MMX.

I don't know.  Perhaps when they wrote it, the STL complex template
wasn't solid or complete.

complex short would be fine.  It also brings up the issue of where's
the radix point.  I.e., 1.15, 2.14, etc., and do you want to attempt
to represent that in the type.

Perhaps we should standardize on a couple of complex formats:

typedef complex<float> VrComplex;       // single precision floating pt
typedef complex<short> VrComplexShort;  // fixed point, 1.15

Looking at the original MMX stuff: they took the floating point
coefficients and scaled them appropriately for the MMX short multiply
and went from there.  This of course prohibits fixed point filter
design techniques that optimize for finite precision coefficients, but
it may not matter.  If the main problem is VrComplexFIRFilter (the
channel filter), it uses a low pass prototype and then folds in the
frequency translation.  This calculation would kill any fixed point
optimization that was done.  Perhaps the transformation of a floating
point to a "what ever is best for your SIMD unit" operation is the
best way to proceed.  

Also, we may be able to get more filter for our mips by using complex
FIR filters as our prototypes, but I'm out of my league here.  Note:
we're computing with complex coeffients anyway as a result of the
frequency translation.  We may as well start with complex as opposed
to real coeffients for the low pass prototype. 

I think that there's room for experimenting with a couple of different
approaches. 

Eric