[Clientapps-cvs] symbianMmf hxmmfstatectrl.cpp,1.4.2.33,1.4.2.34

[Clientapps-cvs] symbianMmf hxmmfstatectrl.cpp,1.4.2.33,1.4.2.34

rrajesh at helixcommunity.org rrajesh at helixcommunity.org
Wed Mar 24 07:16:05 PST 2010


Update of /cvsroot/clientapps/symbianMmf
In directory cvs01.internal.helixcommunity.org:/tmp/cvs-serv4518

Modified Files:
      Tag: hxclient_2_1_0_cayennes
	hxmmfstatectrl.cpp 
Log Message:
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
 
Modified by:  rajesh.rathinasamy at nokia.com
 
Reviewed by: Ashish Gupta
 
Date: 19-Mar-2010
 
Project:  SymbianMmf
 
Error Id:  DALM-83PT9G 
 
Synopsis: Optimization of number of calls to devSound  for SamplesPlayed count
 
Overview:  
PowerSave feature is implemented to allow the playback engine to be in sleep between high water mark and low water mark. It was noticed during CPU profiling that playback engine still runs during the sleep period. This CR also covers the original CR review comments.
 
Analysis:
RunL for timer in mdfaudiodevice invokes OnTimeSync which results in more audio data to be written. Within the same callstack, High water was reached and the callback checks for IsActive to disable timer. Since the callstack is already in RunL, the active object was not active and later the timer was still running. So introduced a flag to handle this case.
 
Proposal also has optimizations to the number of samplesplayed calls invoked on devsound. Introduced member variable in mdfaudiodevice to store the audio time and it will be updated only during the timer RunL. So any calls between RunL will result in returning the cached value. So the possibility of inaccuracy is 30msec which is acceptable.
 
Made an additional modification to mdfdevice for wakeup interval calculation.
Sometimes, it took more time to fill the HWM amount data. Core had read the data from fileformat, but was not pushed to renderer due to the inaccuracy in the playback time. Added an offset of 500msec to HWM to report it as wakeupinterval. Idea is that core will try to send more data and Audio device will pause scheduler based on HWM.
 
In State controller, while querying for Position, it uses its local value or gets it from playback engine. The value queried from playback engine is not updated in state controller which leads to inconsistent time reporting when the playback engine wakes up from sleep.
 
 
Files removed: None
 
Files added:  None
 
Files modified:  
datatype/mdf/audio/dsp/mdfdevsound.h
datatype/mdf/audio/dsp/mdfdevsound.cpp 
datatype/mdf/audio/dsp/mdfauddevice.h
datatype/mdf/audio/dsp/mdfauddevice.cpp
clientapps/symbianMmf/hxmmfstatectrl.cpp
 
 
Image size and heap use impact:  None
 
Module release testing (STIF):  PARTIALLY PASSED  (Failing cases are related to fullscreen, virtual window, playrate)
 
Test case(s) added:  No
 
Memory leak check performed: No. Support not available for mdfauddevice
 
Platforms and profiles build verified: helix-client-s60-50-mmf-mdf-dsp
 
Platforms and profiles functionality verified:  armv5
 
Branch:  210CayS


Index: hxmmfstatectrl.cpp
===================================================================
RCS file: /cvsroot/clientapps/symbianMmf/hxmmfstatectrl.cpp,v
retrieving revision 1.4.2.33
retrieving revision 1.4.2.34
diff -u -d -r1.4.2.33 -r1.4.2.34
--- hxmmfstatectrl.cpp	11 Mar 2010 03:53:19 -0000	1.4.2.33
+++ hxmmfstatectrl.cpp	24 Mar 2010 15:16:02 -0000	1.4.2.34
@@ -297,7 +297,6 @@
 ULONG32
 HXMMFStateCtrl::GetPosition()
 {
-	ULONG32 ulRetPos = m_posLength;
 
 #ifdef HELIX_FEATURE_POWER_SAVE_MODE
 	if(m_pScheduler3
@@ -305,13 +304,12 @@
 	&& m_pPlayerControl
 	&& m_pPlayerControl->m_pHXPlayer)
 	{
-		ulRetPos = m_pPlayerControl->m_pHXPlayer->GetCurrentPlayTime();
+		m_posLength = m_pPlayerControl->m_pHXPlayer->GetCurrentPlayTime();
 	}
 #endif /*HELIX_FEATURE_POWER_SAVE_MODE*/
 
-	return ulRetPos;
+	return m_posLength;
 
-	// return(m_posLength);
 }
 
 ULONG32




More information about the Clientapps-cvs mailing list
 

Site Map   |   Terms of Use   |   Privacy Policy   |   Contact Us

Copyright © 1995-2007 RealNetworks, Inc. All rights reserved. RealNetworks and Helix are trademarks of RealNetworks.
All other trademarks or registered trademarks are the property of their respective holders.