From: Bernard L. <le...@bo...> - 2003-03-04 08:03:38
|
[ CC'ed back to the list :) ] Hi Chandan, Those numbers are interesting, it looks like the audio driver is _really_ wasting that extra cpu! One experiment we could try is to just get the main cpu to do all the work. An extension of that would be to then put the decoding routines in fast ram (since we wouldnt be using it as the buffer). I'm not sure how big a win this would be but it is how the real firmware works... The "fast ram" is onboard ram so I guess its similar speed to the cache?? cheers, bern. On Tue, 2003-03-04 at 06:02, Chandan Kudige [home] wrote: > > Be careful about changing the optimisation level when compiling with > > gcc. -O3 should be faster than -O2, but in a lot of cases it isn't > > (infact -O1 or -Os are sometimes faster than either of them !!). I > > don't think it's going to make it 25% faster, but you should give > > each one a try if possible. > I will give this a try tomorrow. > > > > > Did you try madplay with '-o/dev/null' ?? > > That would give a clue about how much time is spent in madplay and > > how much in the other stuff (e.g. audio output driver etc). > > > > Here are the numbers with /dev/null > For the 128 second clip: > Without patch: 163.00 sec > With patch: 158.47 sec > |