I have the same need on future Intel MID devices where we have the
potential to perform low power audio (with no video), but for 10's of
seconds.
We haven't got around to prototyping any ways of getting around the same
issues that you are seeing, but this sounds like an interesting approach
to me.
--rusty
On Fri, 2008-10-03 at 07:51 -0700, [EMAIL PROTECTED] wrote:
> Any comments on this ?
>
> Thanks,
> Rajesh.
>
>
>
> ______________________________________________________________________
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of ext
> [EMAIL PROTECTED]
> Sent: Wednesday, October 01, 2008 11:18 AM
> To: [email protected]; [EMAIL PROTECTED]
> Subject: [Client-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.
>
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
