Re: Is the Xing decoder EVER going to be replaced with MAD?

Kristian G. Kvilekval wrote:
> On Thu, 2003-03-13 at 13:05, Ed Sweetman wrote:
> 
>>the mad decoder wouldn't be much of an advantage in the current 
>>pipeline.  Mad's power comes mostly from it being a really nice decoder 
>>for low latency needs and our pipeline works on a signal mechanism, 
>>which is horrible for low latency needs.  It would only really make 
>>sense to include a mad mp3 decoder after the pipeline is serialized. 
>>Also, including the mad mp3 decoder doesn't mean the removal of the xing 
>>one. And since mad looks like a future mp3 decoder plugin, we should 
>>also look at tremor as a vorbis plugin. It being integer only means it 
>>can probably be optimized better by the compiler for a given arch and 
>>thus perform better when used in a player such a zinf.
> 
> 
> 
> Eeek.. I read somewhere that tremor uses some fixed point arithmetic
> (good), but also emulates floating point in some places (bad).   The
> last I read suggested staying with the standard decoder if you FP
> hardware and using tremor only when you don't.


Oh?  i was just thinking that since most of the extensions that gcc 
likes to use on non SSE x86 machines are integer only, that it could use 
a whole lot more of them in a compiled tremor decoder than it can use on 
a plain decoder.  But it sounds like all the extra time needed to 
emulate floating point would make those benefits mute.




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en