Intel Atom

Carsten Haitzler (The Rasterman) raster at openmoko.org
Fri Aug 15 09:12:38 CEST 2008


On Thu, 14 Aug 2008 23:30:01 -0700 Russell Sears <sears at cs.berkeley.edu>
babbled:


aaah - i was not really thinking of high quality audio filters - i was really
thinking "ok.. it's a phone - an embedded device. for entertainment and regular
daily use - we need really volume adjustment (to be able to soft-vary multiple
incoming audio streams) and mixing". yes. it's a limited view - but these are
limited devices :) for "practical usage" you need no fp math - not for the
basic audio stuff. sure. more complex filters (when doing actual audio
composition and mixing i would agree you will be wanting more here), but for
regular daily "realtime" use... i can't think of any need for fp math for
audio. (ok - i am skipping games here right now but even so most game audio
still falls into the category of soft-volume and mixing filters and playing
samples).

> Yes, but there's tons of legacy code that assumes an FPU. (ladspa plugins)
> 
> Also, after some naive conversions from floating point to fixed point 
> programming, I hit a situation where 32bit arithmetic doesn't quite cut it.
> 
> Some filters want to multiply two floats together.  You can do this to 
> simulate floating point math:
> 
> float f = ...;  // 0 <= f < 1.
> int a, c;
> 
> const int b = (int)(f * 65536.0)
> 
> while(1) {
>    ... // update a
>    c = a * b
>    c >> 16
>    ... // do more math
> }
> 
> Where a is signal data, perhaps dependent on past data, and b is a 
> filter parameter.  Some formulas derive b from user tunable parameters.
> 
> In some corner cases, f is small (on the order of 1 / 2^16), which leads 
> to rounding error assigning to the filter parameter b.
> 
> This distorts the filter setup, and leads to artifacts, feedback loops, 
> etc.  Using 64 bit math better approximates the filter, and helps these 
> corner cases a bit.  There might also be cases where you'd want to carry 
> 32 bits of precision throughout the calculation, though I haven't hit 
> one yet.
> 
> The good news is that the hit associated with 64 bit math (and a 48 bit 
> filter parameter) is measurable, but tolerable on the FR.
> 
> > 
> >> On a related note (and perhaps on the wrong end of an NDA), any idea 
> >> what the specs are on the glamo's built in openrisc processors?
> > 
> > low to useless. it's slow. also not even under nda is there any info on just
> > how to program it. it's more of a control cpu - designed for keeping the
> > internal bits of glamo's silicon in line than actually doing any heavy
> > lifting of its own.
> 
> Thanks for the info.  That makes sense...
> 
> -Rusty


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>




More information about the community mailing list