Hi Rajesh,
I am now seeing the sample count reset after the resume very consistently. I only see it on the device so far, never in the emulator. I was never seeing this on the device before though and I'm not sure why I am seeing it now. I'm seeing it with local clips that I have been testing with all along and I am positive I did not previously see this behavior.
In your output just before the reset there are 206496 written - 202771 played = 3725 buffered by the dev sound device. Then the next time we call SamplesPlayed we get 660 . At that point it is impossible to know for sure how many samples are unplayed/buffered. It is also impossible to know how many samples have played out since the last check 202771. That is because we don't know if 660 is for samples played since the last call to SamplesPlayed, or if is for samples played since the call to Pause(), or the samples played since the call to PlayData, or some other arbitrary point. I wonder if there is something we are doing that is causing the device to do this. I also wonder if it because I went from building against the 2.0 to the 2.1 sdk at some point.
What does the phone do when it crashes on the pending buffer? Does the player exit or does the phone reboot, freeze, etc? I haven't seen this.
Thanks,
Liam
At 05:35 PM 4/6/2005, [EMAIL PROTECTED] wrote:
Hi Liam,
Attaching the log output where u can notice the stream count reset after pause. And also on this trial I removed the m_pPendingFillBuffer reset to NULL and the phone crashed.
The application works in spite of stream reset during pause is because of the additional check added in ::UpdateSamplesCount(ie double reset check code).
Log Extract: (Added comments with >> << markers for easy interpretation)
=============
Samples Written: 195344
Base Cnt:192652 StreamCnt: 193310
Samples Written: 196368
Samples Written: 197392
Base Cnt:193310 StreamCnt: 194851
Base Cnt:194851 StreamCnt: 195511
Samples Written: 198000
Samples Written: 198416
Samples Written: 199440
Base Cnt:195511 StreamCnt: 196830
Base Cnt:196830 StreamCnt: 197271
Base Cnt:197271 StreamCnt: 197491
Samples Written: 200464
Base Cnt:197491 StreamCnt: 198151
Base Cnt:198151 StreamCnt: 198590
Samples Written: 201488
Samples Written: 202400
Base Cnt:198590 StreamCnt: 200131
Samples Written: 203424
Base Cnt:200131 StreamCnt: 201230
Samples Written: 204448
>>>>>>>>>>>>>>>>>>>>>>> Here Pause was issued and value 0 indicates that the m_pPendingFillBuffer is NULL <<<<<<<<<<<<<<
Pause On PlayState : 0
Play On PauseState
Samples Written: 205472
Base Cnt:201230 StreamCnt: 202771
Samples Written: 206496
>>>>>>>>>>>>>>>>>>>>>>> U can see a stream count reset here <<<<<<<<<<<<<<
Base Cnt:202771 StreamCnt: 660
Samples Written: 206800
Samples Written: 207520
Samples Written: 208544
Base Cnt:202771 StreamCnt: 2354
Base Cnt:202771 StreamCnt: 2574
Samples Written: 209568
Base Cnt:202771 StreamCnt: 3234
Base Cnt:202771 StreamCnt: 3675
Samples Written: 210592
Base Cnt:202771 StreamCnt: 4555
.
.
.
Base Cnt:202771 StreamCnt: 2418
Samples Written: 220000
Base Cnt:202771 StreamCnt: 3078
Base Cnt:202771 StreamCnt: 3520
Pause On PlayState : 0
Play On PauseState
Samples Written: 221024
Base Cnt:202771 StreamCnt: 3958
Samples Written: 222048
Base Cnt:202771 StreamCnt: 658
Samples Written: 223072
Base Cnt:202771 StreamCnt: 1318
Base Cnt:202771 StreamCnt: 1538
Samples Written: 224096
Base Cnt:202771 StreamCnt: 2198
Samples Written: 224400
Base Cnt:202771 StreamCnt: 3298
Base Cnt:202771 StreamCnt: 3739
>>>>>>>>>>>>>>>>>>>>>>>Pause Issued and m_pPendingFillBuffer has some address<<<<<<<<<<<<<<
Pause On PlayState : 427094
>>>>>>>>>>>>>>>>>>>>>>> At this point the phone crashed and not just application.<<<<<<<<<<<<<<
Regards, Rajesh.
-----Original Message----- From: ext Liam Murray [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 3:18 PM To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas); [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: HXSymbianAudioSession
At 12:24 PM 4/6/2005, [EMAIL PROTECTED] wrote: >Hi Liam, > In HXSymbianAudioSession why is the bufferlist freed during a stopped > state. Will this not result in data being lost during KErrUnderFlow case ?
Yes, you are right! We should only discard when Stop is called by the higher level code (or we close), but not in KErrUnderflow. I've already fixed this in my local copy...
>The current problem I see is audio gets stopped after a while. It happens >on the following case: >1. Pause is issued (InternalPause), m_pPendfingFillBuffer reset to NULL. >2. Write is Issued ( Data buffered into BufferList) >3. Play is Issued. Results in Underflow Error and cleans up the >BufferList. And DevSound started again >4. BufferToBeFiled is called by DevSound. But the BufferList is empty. >5. Now it runs on loop and data is not played, timeline does not move. But >when u seek forward, it continues to play properly.
I was going to ask you about this because now I am seeing this after I modified pause to discard m_pPendingFillBuffer. What I see that sometimes our write list is empty when we get a call to BufferToBeFilled. At that point we save the buffer to m_pPendingFillBuffer. If we then get a pause we (now) set m_pPendingFillBuffer = 0.
Then when we resume we call m_pStream->PlayData. After that we never get a call to BufferToBeFilled and the data plays out and then we get KErrUnderflow.
I changed the code back so we don't set m_pPendingFillBuffer NULL. Then in Play I changed the code so we check for m_pPendingFillBuffer as follows.
if (m_pPendingFillBuffer) { BufferToBeFilled(m_pPendingFillBuffer); // calls PlayData } else { m_pStream->PlayData(); }
That seems to work well. We get calls to BufferToBeFilled. I never see crashes or problems using the fill buffer. I also never see the sample count reset. I was wondering if you possibly had made some local changes to call PlayInitL instead of PlayData. Are you seeing these all the time or only with certain clips. I'm still confused about the different observations in bevior between us.
There still is a problem with the higher-level code not writing fast enough, so we still get KErrUnderflow. I think it has to do with the preroll and audio pushdown.
(There was also an error where in Write (if called after we call pause) we would end up calling BufferToBeFilled when we should just add the audio buffer to the list and return.)
Thanks for your help!
Liam
>Hope you did not misunderstand my suggestion of resetting >m_pPendingFillBuffer NULL to discard the pending buffers in list under >Pause condition. > >Thanks, >Rajesh. > > > >
_______________________________________________ Audio-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/audio-dev
