Eric & All, Any comments on this ? The audio device could certainly do that - for each player, iterate through all the streams and find out the ending time for all streams. It would have to look at the "Delay" and "Duration" properties of each stream.
<<Rajesh>> I could evaluate this option. But this approach does not stop sending lot of silence data to the device. If the decision is not made at AudioSession level, (then based on high pushdown value,) it could send around 600 blocks (for 30 sec as audio pushdown) of silence. Thanks, Rajesh. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext [EMAIL PROTECTED] Sent: Wednesday, October 08, 2008 11:34 AM To: [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED] Subject: [Client-dev] RE: [Audio-dev] Audio pushdown & Stream End Eric, Comments inlined. Thanks, Rajesh. -----Original Message----- From: ext Eric Hyche [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2008 8:12 AM To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas); [email protected]; [EMAIL PROTECTED] Subject: RE: [Audio-dev] Audio pushdown & Stream End >What if there are more than one stream, should audio device iter >through to find the max of all duration of stream ? > The audio device could certainly do that - for each player, iterate through all the streams and find out the ending time for all streams. It would have to look at the "Delay" and "Duration" properties of each stream. <<Rajesh>> I could evaluate this option. But this approach does not stop sending lot of silence data to the device. If the decision is not made at AudioSession level, (then based on high pushdown value,) it could send around 600 blocks (for 30 sec as audio pushdown) of silence. Would playlists ever want to be used in this scenario? If so, then the audio device would need to take groups into account. Each "group" is a separate timeline which are sequenced one after the other. For the case of a simple sequential playlist, think of each clip in the playlist as being in a different group. The scheduler would certainly need to be activated at the end of each group, so that the player could switch groups. So I guess the audio device would still only need to know the duration of each group. Eric ======================================= Eric Hyche ([EMAIL PROTECTED]) Principal Engineer RealNetworks, Inc. >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] >Sent: Monday, October 06, 2008 11:20 AM >To: [EMAIL PROTECTED]; [email protected]; >[EMAIL PROTECTED] >Subject: RE: [Audio-dev] Audio pushdown & Stream End > >Hi Eric, > If we are looking at the specific info from decoder, then we might >end up changing in all decoders for which this support is required. > >What if there are more than one stream, should audio device iter >through to find the max of all duration of stream ? > >Let me also try to find whether this support is required only for DSP >solution. If so, it would be easy to get that information as the >MDFDecoder has reference to thev device. >But I would prefer to find a solution that would fit for both ARM >codecs and DSP codecs. > >Thanks for your time and comments. Please let me know if you could >think of any other options. > >Thanks, >Rajesh. > > >-----Original Message----- >From: ext Eric Hyche [mailto:[EMAIL PROTECTED] >Sent: Friday, October 03, 2008 11:49 AM >To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas); >[email protected]; [EMAIL PROTECTED] >Subject: RE: [Audio-dev] Audio pushdown & Stream End > >I would think that your approach could work, but perhaps you might be >able to reliably figure out the end of the audio data. > >You asked before if the audio session knows when the end of stream is. >I said the audio session doesn't really know. However, the audio >decoder *does*. In the IHXAudioDecoder::Decode() call, the last >argument is a bEOF argument, which says that the input encoded buffer >is the last one available. Therefore the decoder should be able to tell >the timestamp of the last frame audio decoded audio data it passes back to the renderer. > >In your scenario, is there any way for the audio device to retrieve >this information from the decoder and then wait for that timestamp to >be written to it? > >Eric > >======================================= >Eric Hyche ([EMAIL PROTECTED]) >Principal Engineer >RealNetworks, Inc. > > >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf Of >>[EMAIL PROTECTED] >>Sent: Wednesday, October 01, 2008 12:18 PM >>To: [email protected]; [EMAIL PROTECTED] >>Subject: [Audio-dev] Audio pushdown & Stream End >> >>Hello All, >> I'm trying to evaluate an idea of pausing & resuming scheduler for >>local playback for CPU optimization. >> >>As a part of this exercise, the AudioPushDown is increased (say 1 or 2 >>minutes). Scheduler will be paused and resumed based on the high and >>low water mark of unplayed data in device. AudioSession >>(client\audiosvc) does not detect end of stream. This results in >>sending lot of silence data to the device. The data is pushed to >>device > >>is based on audio push down (Block count). If audio push down is huge >>(say 1 min), and if the playback is close to duration ( say 50 msec to >end playback), the audio session pushes 1 min of data to device ( >Mostly just silence). >> >>Given the problem, shouldn't the audio pushdown be dependent on >presentation duration. ? Assumption: >>Presentation duration is greater among all stream playback. >> >>NumBlocksReqdToComplete = (PresentationDuration - CurrTime) / >>Granularity >> >>If(uNumBlocksPushed > NumBlocksReqdToComplete) { >> uNumBlocksPushed = NumBlocksReqdToComplete; >> >> // Add a tolerance. >> uNumBlocksPushed += Tolerance. (say 2 blocks, around 100 msecs) } >> >>We will not see this problem most of the time, if our audiopushdown >values are smaller. >> >> >>Thanks, >>Rajesh. _______________________________________________ Client-dev mailing list [EMAIL PROTECTED] http://lists.helixcommunity.org/mailman/listinfo/client-dev _______________________________________________ Audio-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/audio-dev
