Incidentally, the docs on qtIdleRate have an error, they say:
"A higher idle rate will result in smoother playback but will also require more cpu time." but they should say: "A LOWER idle rate will result in smoother playback but will also require more cpu time." Lowering the qtIdleRate from 20 (30% CPU) to 1 (50% CPU) improved playback performance dramatically for me. I wonder what the qtIdleRate represents - maybe a "tick" (1/60 sec)? On Jan 25, 2010, at 3:10 PM, Scott Rossi wrote: > Recently, Colin Holgate wrote: > >> On Jan 25, 2010, at 3:56 PM, Scott Rossi wrote: >> >>> Is there any disadvantage to having >>> a high qtIdleRate value when the only files played by the player will be >>> audio files? >> >> >> You might want to do something else, say a repeat while the mousedown, and >> see >> (or hear) if the sound dries up with different idle settings. > > Well, here's one finding... > > It appears that MP3/4 audio files encoded at a "high" rate (ie 256 kbps) > require a semi-frequent qtIdleRate. After testing several AAC files, I was > able to get 256 kbps tracks to play with a qtIdleRate of 250 -- any rate > longer than this caused large gaps in the playback. > > I will do some more testing but it seems that audio files encoded at "low" > rates -- 128 kbps and lower -- can play fine with a long qtIdleRate > interval. > > Still working on that balance between performance and bogging down the > user's system like molasses in winter... > > Regards, > > Scott Rossi > Creative Director > Tactile Media, UX Design > > > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
