I see the sample count reset even after I call PlayInitL. I also never call SamplesPlayed() unless we are PLAYING (BufferToBeFilled called at least once after PlayInitL.) Rajesh, have you tried calling PlayInitL after a pause? Did that fix the sample count reset for you?
Liam
At 11:02 AM 4/7/2005, [EMAIL PROTECTED] wrote:
Even calling PlayData after pause will do internal intialize so I think behaviour will be same. And X should be quite small.
Ashish
-----Original Message----- From: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas) Sent: 07 April, 2005 12:53 To: 'ext Liam Murray'; Gupta Ashish.As (Nokia-TP-MSW/Irving); [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Porting-symbian] RE: HXSymbianAudioSession
Hi,
Calling PlayInitL during Pause-Resume will solve the problem of Stream count falling back. But what about the following scenario ?
Consider there are some X buffers in DevSound unplayed during Pause. During Resume, if we issue a PlayInitL() what will happen to the X number of buffers pending in DevSound ? My understanding was that PlayInit will Initialize the player apart from sending the buffer through BufferToBeFilled call. So if it is true, the pending buffers in X will not be played and will be discarded. Will this not result in loss of audio data ?
Thanks, Rajesh.
-----Original Message----- From: ext Liam Murray [mailto:[EMAIL PROTECTED] Sent: Thursday, April 07, 2005 12:09 PM To: Gupta Ashish.As (Nokia-TP-MSW/Irving); Rathinasamy Rajesh (Nokia-TP-MSW/Dallas); [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Porting-symbian] RE: HXSymbianAudioSession
At 11:55 AM 4/7/2005 -0500, [EMAIL PROTECTED] wrote: >Usually, in the h/w pause results in the destruction of h/w devices etc. >(below the devsound.) Thus after pause and before the devsound is >initialized its kind of in a un-initialized state. Based on this I have >few suggestions to make in this context. >On the hardware, when play is issued, HXSymbianAudioSession should call >PlayInitL instead of PlayData.
When we first play we do call PlayInitL()?
Do you mean after we call m_pStream->Pause() and then when we want to resume? I was actually wondering about resuming from a pause because the docs are not very clear wheter or not PlayData is in fact the right thing to call (because it seems to be associated more with the calls to BufferToBeFilled and notifying dev sound when you fill the buffer). PlayData always seemed to resume from pause state however...
>It should wait for the operation to complete before using the devsound.
We either get PlayError or a call to BufferToBeFilled after PlayInitL. (I actually have never seen PlayInitL fail, so I always see BufferToBeFilled after PlayInitL.) Is this what you mean by complete?
Thanks as usual for your excellent info! I'm eager to try it out.
Liam
>We can make the Play command asynchronous by removing
>Message().Complete(err) from HXSymbianAudioSession::Play (only for the non
>WINS platforms). It should complete the request when PlayInitL completes.
>That should avoid the problem of sample count going backwards.
>
>On the wins platform, we can continue calling PlayData and then
>immediately calling Message.Complete(err).
>
>Requesting for SamplesPlayed can be requested to the state when DevSound
>is playing i.e. we have issued the play and we have received the first
>BufferToBeFilled call.
>
>Thanks
>Ashish
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] Behalf Of ext Liam
>Murray
>Sent: 07 April, 2005 11:25
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>[EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: [Porting-symbian] RE: HXSymbianAudioSession
>
>
>At 10:58 AM 4/7/2005 -0500, [EMAIL PROTECTED] wrote:
> >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.
>
>Unfortunately depending on how many pauses are issued we would end up with
>a/v sync problems because the timeline would get more and more inaccurate.
>With the underflow we always see the sample play out and we know how many
>samples are buffered at the time of the underflow. We know the reset
>(usually) occurs after those samples written up until the time of the
>underflow play out, so we can stay accurate since we know the when the
>reset actually occurs. It may be that the sample count resets with the next
>CMMFBuffer played after we call PlayData after the pause, or something like
>that. If so we can use that knowledge to determine a way to ensure our
>sample count remains accurate after a reset associated with a resume.
>
>I'm wondering also why I am seeing this now when up until yesterday I was not.
>
>Thanks,
>
>Liam
>
> >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.
> > > >
> > > >
> > > >
> > > >
>
>
>_______________________________________________
>Porting-symbian mailing list
>[EMAIL PROTECTED]
>http://lists.helixcommunity.org/mailman/listinfo/porting-symbian
_______________________________________________ Audio-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/audio-dev
