Hi Liam, Good that you are able to see the problem by yourself. Now we need to see how to tackle this case. Yeah, I understand the case of reset to a sudden small value puts us in a awkward situation of not knowing the exact samples played.
This problem always occurs on device and not on WINS build. DevSound behavior is different from WINS to THUMB. You might also notice that underflow err is never thrown on 6630 device which occurs on WINS. What If we do similar handling to that of KErrUnderflow ? I.e. Enable ResentPendingFlag and allow the basecount to get reset once the stream count goes less than the base count value. When the phone crashes on pending buffer, it reboots the phone. You may not see this crash for every Pause and resume. The scenario of BufferPending should not be NULL during a pause and later a Resume will result in a Phone crash. Thanks, Rajesh. -----Original Message----- From: ext Liam Murray [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 10:22 PM To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas); [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: HXSymbianAudioSession 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
