I presume you are looking at doing this AudioPushDown increase for
local playback only?? For streaming this would be extremely bad user
experience, as the 1 minute push down would mean 1 minute start-up
time before playback can begin after streaming starts. Normally
AudioPushDown should definitely NOT be based on duration (if there
even is one). Also it is probably worth noting that such large audio
push down would presuming have quite large memory impact, so you
would have to take into account the available memory.
Jamie
[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.
------------------------------------------------------------------------
_______________________________________________
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
