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