[Scummvm-devel] Ogg (Tremor) on low-end devices

[Max Horn]

Am 29.06.2007 um 15:39 schrieb Robin Watts:

> Hi all,
>
> Sorry for not having replied to this sooner, but it appears that
> emails aren't making it to me from this list :(
>
> To summarise what I think the state of play with Tremor/Tremolo is:
>
>  * Tremolo is an (my) ARM optimised version of v1.0 of Tremor. It
> runs faster than Tremor - my timings for how much are probably a tad
> bogus due to the hardware I was testing it on, but I believe it to be
> significantly faster.
>
>  * Tremor has been upgraded a couple of times with bug fixes (it's
> now at 1.0.2), and I've pulled those fixes back into Tremolo.

Sounds nice, but is this lib available under a license that makes it  
possible to use it? Did anbyody perform tests with it? And anyway, I  
still am not quite sure which of our ports support Ogg, which MP3,  
and which both/neither... ;)

>
>  * Tremor has also been upgraded with a low memory mode and a low
> accuracy mode. The low memory mode, I haven't looked at in detail.
> The low accuracy mode (which saves 50K of lib size due to reduced
> tables) reduces the quality we get out. Supposedly it saves 15% of
> CPU.
>
>  * Tremolo has not been updated with the low accuracy mode, and I'm
> in two minds as to whether it's really a good idea - one of the aims
> of Ogg Vorbis is superior audio quality - do we really want to throw
> that away in exchange for faster decoding?

Want, no. But if it's the difference between being unable to use Ogg  
at all, and being able to use it... ?

> Anyway, my belief is that
> Tremolo is still faster, as the tremolo ARM coding should be worth
> noticably more than 15%.

Fine. For the ARM ports at least (PSP has a MIPS R4000, for example).  
And of course even those 15% might be not enough (anybody know about  
the situation on the DS, for example?).


> * The thesis referred to in the links posted by Fingolfin earlier is
> interesting, but it's main claim appears to be "We used FFT instead
> of MDCT and it went 8 times faster". It's a slightly suspect claim as
> they apparently used an assembly FFT on a DSP and compared the time
> to using the existing MDCT code on the same DSP, where the existing
> MDCT is written to make use of a 32*32 -> 64 operation that that DSP
> didn't provide.

Aye, true, and well-discussed in the thread I posted a link to.  
However, the point he made also was that highly optimized FFT  
implementations exist for many systems, often the system vendors  
spend considerable amounts of energy to tweak those to the max, so  
being able to reap that benefit can pay off.

Did you take a look at the other patches which supposedly improve  
efficiency?

Cheers,
Max