Pankaj,
   Timing calculation can be configured to use samples written or
samples played. The compiler define for it is
HELIX_CONFIG_SYMBIAN_SAMPLESPLAYED. If this flag is defined then audio
session will use SamplesPlayed API to calculate time. 

We did notice AV Sync problem on 8Khz sampling rate alone when the above
flag was not defined (ie while using samples written calculation). After
turning on the HELIX_CONFIG_SYMBIAN_SAMPLESPLAYED flag, there is no AV
sync.

Using Systemtime is somewhat similar to using the SamplesWritten
calculation. If DevSound takes a little longer time to output the data,
then we will still have the AV sync issue.

Regards,
Rajesh.


>-----Original Message-----
>From: ext Pankaj Gupta [mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, April 12, 2006 8:54 AM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas); [EMAIL PROTECTED]
>Cc: [email protected]
>Subject: RE: [Audio-dev] CR: Fix to improve symbian player performance
>
>Hi Rajesh
>
>Thanks for suggestions.
>
>I verified that the problem is not because of pause. I also 
>looked into the 210cays code and here the time calculation is 
>based on the number of samples written into the buffer instead 
>of SamplesPlayed call. But when I put there same logic in 
>150cay the audio Video sync was lost and audio started lagging 
>behind Video. I am trying to put some workaround in GetTime so 
>that I can use SytemTime  along with the 210s logic to resolve 
>this issue. Just need to verify did anyone noticed audio video 
>sinking problem on 210CayS?
>
>Regards
>Pankaj
>
>
>At 11:48 PM 4/11/2006, [EMAIL PROTECTED] wrote:
>>Greg & Pankaj,
>>   SamplePlayed count used to reset on pause for 6630. Code has been 
>>added to handle this case. I think the code should be 
>available for 150 
>>cay too.  But the handling was initially enabled only for 6630. Later 
>>Dextra found the same problem for 6680 and updated the check 
>to enable 
>>for that device too.
>>
>>It may be worth looking in that too. (
>>HXSymbianAudioSession::HXSymbianAudioSession) Just try 
>turning on that 
>>boolean variable to see whether it solves your problem.
>>
>>TInt uid = 0;
>>     TInt res = HAL::Get(HALData::EMachineUid, uid);
>>     if (KErrNone == res)
>>     {
>>         if (DEVICE_UID_6630 == uid || DEVICE_UID_6680 == uid )
>>         {
>>             m_deviceResetsOnPause = TRUE;
>>         }
>>         HXLOGL3(HXLOG_ADEV,
>>"HXSymbianAudioSession::HXSymbianAudioSession(): symbian device uid = 
>>0x%08x", uid);
>>     }
>>
>>210Cay also has some code to accommodate lost samples during 
>pause case.
>>
>>
>>  For all Symbian 9.x, this flag is turned on.
>>
>>-Rajesh.
>>
>>
>> >-----Original Message-----
>> >From: ext Greg Wright [mailto:[EMAIL PROTECTED]
>> >Sent: Tuesday, April 11, 2006 1:08 PM
>> >To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas)
>> >Cc: [EMAIL PROTECTED]; [email protected]
>> >Subject: Re: [Audio-dev] CR: Fix to improve symbian player 
>> >performance
>> >
>> >[EMAIL PROTECTED] wrote:
>> >>  Hi Pankaj,
>> >>     Even though Audio session writes data in chunks to DevSound, 
>> >> the SamplesPlayed API is supposed to report the samples 
>Played stat 
>> >> in real time. It should not wait for the complete playout of data 
>> >> to report samples played. For example even if u write 200msecs
>> >of data in
>> >> one shot, the samplesPlayed will be queried for every 30msec
>> >interval
>> >> and the samplesplayed api should start reporting the progress 
>> >> counts instead of waiting for 200msec to playout.
>> >>
>> >> Now the code increases the number of BTBF 
>(BufferToBeFilled ) calls.
>> >> More number of BTBF calls results in that many server-client 
>> >> interaction (and also that many copy on buffers
>> >descriptor)on the DevSound layer.
>> >>
>> >>  Apart from that the Audio buffer flow between AudioSession and 
>> >> Engine's audio layer is already throttled by BlocksBufferred
>> >API. Too
>> >> much of data accumulation would not happen on the Audio session. 
>> >> The Supply of data will be cut down from engine's Audio 
>Service to 
>> >> Audio-session which means u may not have lot of data in 
>AudioSession.
>> >>
>> >> If SamplesPlayed reporting is jumping in a big number, then this 
>> >> change might actually hide the problem in DevSound.
>> >>
>> >> What version of Symbian u r running ? (Is that Series 60 or UIQ )
>> >
>> >FYI,
>> >
>> >Pankaj is trying to fix playback problems on a Nokia 6600. 
>The 150Cay 
>> >branch does not playback as well as the 142NepX branch.
>> >
>> >--greg.
>> >
>> >
>> >>
>> >> Hope it helps !
>> >>
>> >> Thanks,
>> >> Rajesh.
>> >>
>> >>
>> >>
>> >>
>> >>> -----Original Message-----
>> >>> From: [EMAIL PROTECTED]
>> >>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> >ext Pankaj
>> >>> Gupta
>> >>> Sent: Tuesday, April 11, 2006 5:33 AM
>> >>> To: [email protected]
>> >>> Subject: [Audio-dev] CR: Fix to improve symbian player 
>performance
>> >>>
>> >>> Modified by: [EMAIL PROTECTED]
>> >>>
>> >>> Date :11/04/2006
>> >>>
>> >>> Issue :Performance issue in 150 cayenne symbian player
>> >>>
>> >>> Overview:
>> >>>
>> >>> In 150Cayenne symbian player video is not smooth and
>> >observed visible
>> >>> frame dropping usually once per second.
>> >>> This is happening because the audio device is not driving time 
>> >>> line smoothly.
>> >>>
>> >>> In
>> >>> audio\device\platform\symbian\audiosvr\mmf\audio_session-mmf.cp
>> >>> p file the time calculation is based on SamplesPlayed 
>returned by 
>> >>> device/samplingRate.
>> >>>
>> >>> The HXSymbianAudioSession::BufferToBeFilled() function writes 
>> >>> large amount of data in device because of which
>> >>> m_pStream->SamplesPlayed() function returns same value for
>> >quite some
>> >>> time and then suddenly returns higher value causing sudden time 
>> >>> change of the tune of ~500ms.
>> >>>
>> >>> Fix.
>> >>>
>> >>> In HXSymbianAudioSession::BufferToBeFilled() function is
>> >writing only
>> >>> one buffer from the m_bufferList at a time. This same fix
>> >was applied
>> >>> in 142NeptuneX branch also.
>> >>>
>> >>> Platform: symbian
>> >>>
>> >>> Branch : 150Cay
>> >>>
>> >>> File Modified:
>> >>>
>> >>> - 
>audio/device/platform/symbian/audiosvr/mmf/audio_session-mmf.cpp
>> >>>
>> >>> Files Added: Nil
>> >>>
>> >>> Thanks and Regards,
>> >>> Pankaj Gupta
>> >>>
>> >>> CVS Diff:
>> >>>
>> >>> Index: audio_session-mmf.cpp
>> >>> 
>==================================================================
>> >>> =
>> >>> RCS file:
>> >>> /cvsroot/audio/device/platform/symbian/audiosvr/mmf/audio_sessi
>> >>> on-mmf.cpp,v
>> >>> retrieving revision 1.4.2.6
>> >>> diff -u -w -r1.4.2.6 audio_session-mmf.cpp
>> >>> --- audio_session-mmf.cpp   20 Apr 2005 23:50:58 -0000   
>   1.4.2.6
>> >>> +++ audio_session-mmf.cpp   11 Apr 2006 10:30:54 -0000
>> >>> @@ -981,7 +981,12 @@
>> >>>
>> >>>      //HXLOGL4(HXLOG_ADEV,
>> >>> "HXSymbianAudioSession::BufferToBeFilled(): req size = %ld; dest 
>> >>> buffer size = %lu; desc max = %lu; buffer list count = %ld",
>> >>> aBuffer->RequestSize(), aBuffer->BufferSize(), 
>dataDesc.MaxSize(),
>> >>> m_bufferList.GetCount());
>> >>>
>> >>> -    while ( !m_bufferList.IsEmpty() && cbDest >= m_cbSample)
>> >>> +    // Used if statement in place of while as writing
>> >complete data
>> >>> + causes
>> >>> sudden
>> >>> +    // large time differences in GetTime() calls. Since
>> >>> m_pStream->SamplesPlayed()
>> >>> +    // returns same value for quite some time and then
>> >>> suddenly returns
>> >>> higher value,
>> >>> +    // which causes sudden jump of around 300ms-700ms 
>in GetTime 
>> >>> + calls
>> >>> causing
>> >>> +    // TimeSync problem and frame dropping in vidrend.cpp
>> >>> +    if ( !m_bufferList.IsEmpty() && cbDest >= m_cbSample)
>> >>>      {
>> >>>          // get buffer at front
>> >>>          IHXBuffer* pBuffer = (IHXBuffer*)m_bufferList.GetHead();
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Audio-dev mailing list
>> >>> [email protected]
>> >>> http://lists.helixcommunity.org/mailman/listinfo/audio-dev
>> >>>
>> >>
>> >> _______________________________________________
>> >> Audio-dev mailing list
>> >> [email protected]
>> >> http://lists.helixcommunity.org/mailman/listinfo/audio-dev
>> >>
>> >
>
>
>

_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev

Reply via email to