On Mon, 2007-12-31 at 12:52 +0000, ext Simon Pickering wrote: > >> It is interesting if it is possible to lock ARM/DSP frequency at 400/166 > >> instead of 330/220 when playing video. That would probably improve > >> built-in player performance on some heavy bitrate/resolution videos. > > Would this be possible then? What knocks the CPU speed down when the > DSP is used (or rather when a music file is played)?
A dsp task loaded changes the cpufreq policy, so that the only allowed frequency for ARM is 330 Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. > The media player > presumably? Assuming it is the media player that makes the change, I > presume that mplayer should run at 400MHz all the time? If mplayer is not using any dsp codec, it should already be in such case. > > Sadly, because of DSP sw issues, little power saving is possible when > > the DSP is running (ARM can still go to idle and most of the processor > > can have its clock gated, but it's not possible to reach OMAP > > retention). It would be nice to have the DSP able to sleep between > > frames; the time taken to decode an mp3 frame is significantly shorter > > than the related playback. > > Presumably the background IDL thread implements power saving functions > and is present in the dsp kernel? What actually prevents the DSP from > sleeping between frames? Far from optimal design. In other word there has not been enough commitment to push the sw envelope so that it could actually leverage what the hw can do. The current architecture met the (relatively relaxed) time requirement that were set and therefore it didn't receive any further improvement. > If the mp3 task is written using semaphores > around the data transfer/notification functions, shouldn't the task > yield to the background thread after it has decoded a frame and DMA'd > it to the audio codec hardware? The mixer is still running and it has a significant timeout, iirc. Also, 'm not so sure that the tasks are actually behaving so nicely. I'm not really into audio, but if you try to decode some mp3 that requires a lot of dsp time vs one that requires very little (silence?), I'm almost certain that there will be no sigificant difference in terms of power consumption. It should be easy to verify with a large enough SD and some mp3 handcrafting skills (several copy & paste of the right type of data should be enough). -- Cheers, Igor Igor Stoppa <[EMAIL PROTECTED]> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
