These changes look good.

=============================================
Eric Hyche (ehyche at real.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: helix-client-dev-bounces at helixcommunity.org 
> [mailto:helix-client-dev-bounces at helixcommunity.org] On 
> Behalf Of Milko Boic
> Sent: Tuesday, September 26, 2006 8:05 AM
> To: helix-client-dev at helixcommunity.org
> Subject: [Helix-client-dev] CR-Client: Player core stability fixes
> 
> Modified by: milko at real.com
> Date: 9:26:06
> Project: Atlas
> 
> Synopsis: Player core stability
> 
> Overview:
> The submission includes a number of correction to a number of defects 
> discovered whil testing more complex (multi-track) 
> presentations.  It also 
> includes changes previously presented in "Client Performance 
> Work part 5" 
> while incorporating feedback on the changes.
> 
> -> Properly handle addition and resumption of an audio stream 
> to a playing 
> audio session.  Audio player in such case will initiate 
> E_PLAYING audio 
> state change which in case of already playing audi dession 
> will rewind, 
> reset and resume the audio device.
> 
> -> Added a bunch of logging statement in method improtant for 
> monitoring 
> multi-track operation and performance.
> 
> -> Corrected audio session not to stall in case of rebuffer 
> occured in the 
> process of resuming.  Previously in such case (although very 
> rare), the 
> playback would never start or resume.
> 
> -> Corrected treatment of audio stream last write time 
> rleative to stream 
> base time and stream delay for live streams.  Live streams do 
> not start at 
> 0 but at an arbitray time-stamp.  Any treatment of this value 
> in absolute 
> comparision is invalid as done previosly.  The stream base 
> time is the 
> audio stream starting time in renderer time coordinate 
> system.  The delay, 
> is the amount of time the stream is to be delayed relative to 
> the value of 
> the time-line from the moment of the introduction of the 
> audio stream into 
> the audio session.  This is accomplished by modifying the 
> last write time 
> to create the needed gap indicated by the delay.  The 
> wrap-around is not an 
> issue as it detected and accounted for at the time new audio 
> data is written.
> 
> -> Made audio player an InterruptSafe object thus causing 
> fake time-line 
> (used when no audio is played) to fire OnTimeSync from either 
> system or 
> interrupt thread thus increasing the performance of non-audio 
> presentations.
> 
> -> Made audio session device setup callback interrupt only 
> since it is used 
> to create the audio device on interrupt time thread for performance 
> reasons.  The callback used to be InterruptSafe which meant 
> it could fire 
> on either system or interrupt time thread.  When fired on 
> system thread, 
> the devise set-up callback would reschedule until interrupt time was 
> obtained.  This resulted in delays of re-starting of audio 
> device in some 
> cases.
> 
> -> Removed assert from buffer manager insisting that per 
> stream evet lists 
> be empty on its initialization.  This is no longer the case 
> as per stream 
> event lists hold data not counted towards buffering in case 
> of file-source 
> playback (equivalent to transport buffer) and they are valid to be 
> prepopulated before the buffer maneger is started.
> 
> -> From the player perspective, we are buffering only if we are not 
> playing.  That is, even if one of the sources is buffering 
> and the source 
> did not pause the player, this is background buffering not 
> relevant at 
> player level.  This situation may arrise when source is 
> introduced and 
> buffering ahead of its due begin time thus its buffering not 
> affecting the 
> playback.
> 
> -> On OpenTrack in the player object, scheduled an immediate player 
> callback (ProcessIdle) to speed up processing of the added source.
> 
> -> Removed time check within ProcessCurrentEvents in order to 
> dispatch all 
> queued events unconditionally.  The time check was 
> unnecessary as it was 
> already done at time of insertion into the queue.
> 
> -> Made OnBegin firing tolerance (granularity) be 
> m_ulPlayerUpdateInterval 
> as that is the frequency we can expect OnBegin firing to be 
> considered and 
> we prefer to be a bit early in OnBegin call rather than late.
> 
> -> Made HXPlayer::CalculateOnBeginTime the center of 
> establishing the begin 
> time for all cases as well as for establising the difference 
> between player 
> and renderer timem cooridinate system 
> (pRendInfo->m_ulTimeDiff) which is 
> non-zero in  case of live presentations.
> 
> -> Simplified overly verbose logic for applying the 
> pRendInfo->m_ulTimeDiff 
> to various time stamps.
> 
> -> For shared wallclock, corrected time-stam comparison to be 
> indifferent 
> to magnitude of time-stamps.  Previous logic would fail in case of 
> time-stamp around.
> 
> -> When resetting the source start-time (normally done due to shared 
> wall-clock synchronization), hndled the case when the source needing 
> starting time rest back is already playing by delaying the 
> source by the 
> difference between its current effectve start time and newly 
> desired start 
> time.  This allows for proper synchronization of wall-clock 
> synchrnoized 
> source when one such source is introduced into the playback 
> while other is 
> already playing.
> 
> -> Corrected the logic for setting of the start-time for live streams 
> within the source.  The previous logic was relying on 
> receiving at least 
> one packet from each stream of a live source before starting 
> the rendering 
> of the source in order to compute the minimum start-time and 
> use it as a 
> starting point for all streams. Otherwise, it would attent to 
> adjust the 
> start-time of the streams while the source is playing (being 
> renderered) 
> which is not possible.  Since it is possible for all streams 
> not to arrive 
> by the time the source rendering is started (e.g. based on wall-clock 
> preroll), any change in start time after the rendering is 
> started is now 
> ignored.
> 
> -> Corrected deadlock in base video renderer possible in any 
> threaded build 
> using OS granularity boosting for enhancing the display blt 
> accuracy.  The 
> dealock occured when a decoder object, while holding onto a 
> decode mutex 
> called a Blt method to display a due frame and thus 
> attenoting to acquire 
> the display mutex.  At the same time, the renderer being in 
> porcess of 
> displaying a frame, releasing a stale video frame and thus 
> activating the 
> decoder explicitly (due to decoder thread not being started yet) to 
> backfill the released frame with another decoded frame.  The 
> deadlock is 
> resolved by renderer envoking decoder to backfill for a 
> released frame 
> outside of the display mutex.
> 
> 
> Files Modified:
> /client/audiosvc/hxaudply.cpp,v
> /client/audiosvc/hxaudses.cpp,v
> /client/audiosvc/hxaudstr_new.cpp,v
> /client/audiosvc/pub/hxaudply.h,v
> /client/audiosvc/pub/hxaudses.h,v
> /client/core/buffmgr.cpp,v
> /client/core/hxflsrc.cpp,v
> /client/core/hxplay.cpp,v
> /client/core/hxsrc.cpp,v
> /client/core/srcinfo.cpp,v
> /client/core/srcinfo.h,v
> /client/core/pub/hxplay.h,v
> /datatype/common/vidrend/vidrend.cpp,v
> /datatype/common/vidrend/vidrendf.cpp,v
> /datatype/common/vidrend/pub/vidrend.h,v
> /datatype/common/vidrend/pub/vidrendf.h,v
> /datatype/rm/audio/renderer/rarender.cpp,v
> /datatype/smil/renderer/Umakefil,v
> /datatype/smil/renderer/smil2/Umakefil,v
> /datatype/smil/renderer/smil2/smldoc.cpp,v
> /datatype/smil/renderer/smil2/smlrendr.cpp,v
> /common/build/BIF/helix.bif
> 
> Image Size and Heap Use impact (Client -Only):
> insignificant
> 
> Platforms and Profiles Affected:
> all
> 
> Distribution Libraries Affected:
> none
> 
> Distribution library impact and planned action:
> n/a
> 
> Platforms and Profiles Build Verified:
> win32-i386-vc7, helix-client-all-defines
> 
> Platforms and Profiles Functionality verified:
> win32
>