Re: CN: www/2009/devdocs/XFP-SOD-CrossFadePlayer.doc

I've updated and checked in the SOD doc with Eric's suggestions.  I'm 
going to go ahead and start implementing these changes as well.  At what 
point should I start submitting CR's for this project?  As I mentioned 
previously, I'd like to start checking in before the project is complete.

Here is a summary of the changes I made to the SOD, in case you don't 
want to re-read the whole thing (and since we can't do a diff of a word 
doc).

I originally meant that the plugin should be put in client/xfadeplayer 
(not xfadeplugin), so that has been changed.

I added this section to explain the division into sub-umakefiles and the 
use of IHXComponentPlugin and IHXContextUser:

4.2. Plug-in Architecture
The cross-fade player will be implemented using two sub-Umakefiles.  One 
will create a static library, which will be useful for users who don’t 
make use of a plug-in architecture.  The other will create a helix 
component plug-in DLL.  This DLL will implement the IHXComponentPlugin 
interface in order to allow the media engine to automatically create 
instances of the cross-fade player object via its CLSID.  The player 
object will implement IHXContextUser, which will allow the media engine 
to automatically provide it with a client context via the 
RegisterContext() function.  Through this mechanism the player will be 
able to acquire the IHXClientEngine and create its internal IHXPlayer 
objects.

I also re-wrote the testing provisions section:

6. Testing Provisions
A simple command-line test application will be committed to a “test” 
subdirectory.  This application will accept two URL parameters to be 
played, as well as some parameters to control the cross-fade experience. 
  It will play the first URL and cross-fade to the second (or perform a 
gap-less transition if no crossfade parameters are specified).



Nicholas Hart wrote:
> thanks for the feedback, this is good info.
> 
> 
> Eric Hyche wrote:
>> Nick,
>>
>> Sorry for the delay in providing feedback. Here's mine:
>>
>> 1) I like client/xfadeplayer instead of client/xfadeplugin,
>>    although whatever you choose will be fine.
>>
>> 2) Inside of client/xfadeplayer, I would have two sub-Umakefil's:
>>    one that builds the IHXCrossFadePlayer into a static lib,
>>    and the other sub-Umakefil that builds an Atlas component
>>    plugin (and links in the static lib built in the other    
>> sub-Umakefil).
>>
>>    A component plugin is one that implements IHXComponentPlugin.
>>    This interface tells the media platform that this plugin
>>    can create certain CLSID_xxx's. It specifies how many CLSID_xxx's
>>    it can create via IHXComponentPlugin::GetNumComponents()
>>    and it provides the list of CLSID_xxx's via
>>    IHXComponentPlugin:: GetComponentInfoAtIndex().
>>
>>    The IHXCrossFadePlayer object should also implement IHXContextUser.
>>    That way, when the plugin handler creates it, it will automatically
>>    pass it the context via IHXContextUser::RegisterContext.
>>
>>    See client/netwksvc/hxnetwksvcpln.cpp, 
>> client\autoupgdmgr\autoupgdpln.cpp,
>>    client\downloadmgr\downloadpln.cpp, or client\core\hxmedengpln.cpp
>>    for examples of component plugins.
>>
>> 3) When an application uses an IHXPlayer, then it:
>>
>>     - loads the media platform
>>     - QI's the media platform for CCF
>>     - uses CCF to create IHXClientEngine
>>     - uses IHXClientEngine to create IHXPlayer
>>
>>    So for IHXCrossFadePlayer, it will:
>>
>>     - load the media platform
>>     - QI the media platform for CCF
>>     - use CCF to create IHXCrossFadePlayer. The plugin
>>       handler will make sure that the object gets a context
>>       via its IHXContextUser::RegisterContext() method.
>>       The context that it is passed will *be* the media
>>       platform.
>>
>>    There is no need to specifically have the application create
>>    a client engine and pass it to the IHXCrossFadePlayer object.
>>    The crossfade player object has a context, so it can create
>>    a client engine internally itself and then manage the
>>    lifetime of that client engine.
>>
>> 4) Under "Testing Provisions", I would suggest a command-line
>>    test app in client/xfadeplayer/test. You could use splay
>>    as a starting point for that, or better yet, use my dirt-simple
>>    SHAPE (Simplest Helix Audio Player Ever) player at
>>    clientapps\samples\shape as a starting point.
>>
>>
>> Eric
>>
>> =======================================
>> Eric Hyche ([email protected])
>> Principal Engineer
>> RealNetworks, Inc.
>>
>>
>>> -----Original Message-----
>>> From: [email protected] 
>>> [mailto:[email protected]]
>>> On Behalf Of Nicholas Hart
>>> Sent: Wednesday, February 18, 2009 4:48 PM
>>> To: [email protected]
>>> Subject: Re: [Helix-client-dev] CN: 
>>> www/2009/devdocs/XFP-SOD-CrossFadePlayer.doc
>>>
>>> there has been zero commentary on this proposal.
>>>
>>> I'm at a point where I'd like to start checking in some files.  The
>>> project is by no means finished, but I'd like the security of keeping my
>>> work in CVS in case my hard drive gets fried.
>>>
>>> Should I start submitting some code reviews to this alias?
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>> Nicholas Hart wrote:
>>>> Modified by: [email protected]
>>>> Reviewed by:
>>>> Date: 2/11/09
>>>> Project: internal RealNetworks product
>>>>
>>>> Synopsis: SOD for client feature to enable cross-fade and gap-less
>>>> playback of audio clips
>>>>
>>>> Overview: I've committed a SOD for a new player object which uses the
>>>> client engine to perform a cross-fade between two audio clips.
>>>>
>>>> Files Added:
>>>> [File 1]
>>>> https://helixcommunity.org/viewcvs/helix-client/www/2009/devdocs/XFP-SOD- 
>>>>
>>> CrossFadePlayer.doc?view=log
>>>> - SOD for this feature
>>>>
>>>> Platforms and Profiles Affected:
>>>> none - SOD only
>>>>
>>>> Platforms and Profiles Functionality verified:
>>>> none - SOD only
>>>>
>>>> Branch:  HEAD
>>>>
>>>> Copyright assignment:
>>>>
>>>>    4.      I am a RealNetworks employee or contractor
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Helix-client-dev mailing list
>>>> [email protected]
>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>
>>>>
>>> _______________________________________________
>>> Helix-client-dev mailing list
>>> [email protected]
>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>
>>
>>
> 
> _______________________________________________
> Helix-client-dev mailing list
> [email protected]
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
> 
>