From snelson at real.com  Tue Oct  3 10:30:21 2006
From: snelson at real.com (Scott Nelson)
Date: Tue Oct  3 11:45:44 2006
Subject: [Player-dev] Adding datatype_aac_codec_helixaac to
	realplay_player_client_engine target
In-Reply-To: <6.2.1.2.2.20060929192628.236eaaf0@mailone.real.com>
References: <019c01c6e1f7$5dc82f90$da8e17ac@D600HB>
	
	<000c01c6e32d$dd18a090$9749e1b0$@com>
	<6.2.1.2.2.20060929192628.236eaaf0@mailone.real.com>
Message-ID: <6.2.3.4.2.20061003102916.026f8e90@mailone.real.com>

Isn't there more info about AAC Fixed Point here?

https://datatype.helixcommunity.org/2005/aacfixptdec

Scott Nelson


At 07:30 PM 9/29/2006, Daniel Yek wrote:

>This AAC codec is from Coding Technology.
>
>This is the only clue that I can find:
>
>datatype/acc/codec/helixacc/platform/win/raac.rc:
>VALUE "LegalCopyright",  HXVER_COPYRIGHT "and Coding Technologies"
>
>
>We don't seem to have source code to this component, do we?
>
>
> > The plan for Balto mentions adding the fixed-point cross-platform AAC
> > codec under the Cayenne integration area.
> > https://player.helixcommunity.org/2005/dev/plans.html
>
>That page actually says:
>Open source, cross platform fixed point AAC code
>
>It doesn't seem like it is correct.
>
>
>--
>Daniel Yek
>
>
>At 11:42 AM 9/28/2006, Haydon Boone wrote:
>> > Would this be the Helix one or the CT one?
>>
>>Helix.
>>
>> > The plan for Balto mentions adding the fixed-point cross-platform
>> > AAC codec under the Cayenne integration area.
>>
>>Right. And the codec team subsequently said that this was unnecessary.
>>
>> > Does our CT license cover Linux desktops?
>>
>>Yes, and I believe it's what is already in-use/shipping in current Linux RP
>>10 builds.
>>
>> > -----Original Message-----
>> > From: Donya Shirzad [mailto:dshirzad@real.com]
>> > Sent: Wednesday, September 27, 2006 1:30 PM
>> > To: hboone@real.com; 'Daniel Yek'; 'Player-dev'
>> > Subject: RE: [Player-dev] CN-Client: Adding datatype_aac_codec_helixaac
>> > to realplay_player_client_engine target
>> >
>> > The plan for Balto mentions adding the fixed-point cross-platform AAC
>> > codec under the Cayenne integration area.  Would this be the Helix one
>> > or the CT one?
>> > https://player.helixcommunity.org/2005/dev/plans.html
>> >
>> > Does our CT license cover Linux desktops?
>> >
>> > Thanks,
>> > - Donya
>> >
>> > At 10:39 PM -0700 9/26/06, Haydon Boone wrote:
>> > >  Is this the RN-developed AAC implementation or the earlier AAC
>> > >implementation that we licensed from Coding Technologies, prior to
>> > >availability of the RN implementation?
>> > >
>> > >  Opinion expressed by our codec team was that, for at least the next
>> > >version of the desktop RealPlayer products, there were not significant
>> > >gains to be seen in moving away from the CT implementation, so we
>> > >should continue to use it in these products for this next product
>> > cycle...
>> > >
>> > >-/Haydon
>> > >
>> > >>  -----Original Message-----
>> > >>  From: player-dev-bounces@helixcommunity.org
>> > >>  [mailto:player-dev-bounces@helixcommunity.org] On Behalf Of Daniel
>> > >> Yek
>> > >>  Sent: Tuesday, September 26, 2006 5:49 PM
>> > >>  To: Player-dev
>> > >>  Subject: [Player-dev] CN-Client: Adding
>> > datatype_aac_codec_helixaac
>> > >> to realplay_player_client_engine target
>> > >>
>> > >>  Thanks, Bob.
>> > >>
>> > >>  This is now checked in.
>> > >>
>> > >>
>> > >>  --
>> > >>  Daniel Yek
>> > >>
>> > >>
>> > >>  At 02:12 PM 9/26/2006, Bob Clark wrote:
>> > >>  >Looks good, Daniel.
>> > >>  >--Bob
>> > >>  >
>> > >>  >At 07:03 PM 9/25/2006, Daniel Yek wrote:
>> > >>  >
>> > >>  >>Modified by: dyek@real.com
>> > >>  >>Date: 9/25/2006
>> > >>  >>Project: Helix Player
>> > >>  >>
>> > >>  >>Synopsis: The HEAD branch of Linux RealPlayer was missing
>> > >> components  >>needed to
>> > >>  >>   play back raac content. This change includes the capability.
>> > >>  >>
>> > >>  >>Overview:
>> > >>  >>   It is unclear to me whether datatype_aac_codec_helixaac
>> > >>  was left out
>> > >>  >>   intentionally or unintentionally.
>> > >>  >>   I'm adding it now to the BIF files used by the HEAD branch.
>> > >>  >>
>> > >>  >>   datatype_h263 exists in hxplay_player_client_engine module
>> > that
>> > >>  >>   realplay_player_client_engine depends on, so it appears
>> > >>  to be redundant
>> > >>  >>   and removed:
>> > >>  >>
>> > >>  >>   > > >>  type="name_only">
>> > >>  >>     ...
>> > >>  >>     
>> > >>  >>     ...
>> > >>  >>     datatype_h263
>> > >>  >>     ...
>> > >>  >>     
>> > >>  >>   
>> > >>  >>
>> > >>  >>
>> > >>  >>Files Modified:
>> > >>
>> > >> >>$BUILD_ROOT/bif-
>> > cvs/helix/client/build/BIF/realplay_gtk_current.bif
>> > >>  >>
>> > >>  >>Platforms and Profiles Affected:
>> > >>  >>Linux
>> > >>  >>
>> > >>  >>Platforms and Profiles Build Verified:
>> > >>  >>Profile: helix_client_all_define
>> > >>  >>Platform: Fedora Core 5
>> > >>  >>
>> > >>  >>Platforms and Profiles Functionality verified:
>> > >>  >>Profile: helix_client_all_define
>> > >>  >>Platform: Fedora Core 5
>> > >>  >>
>> > >>  >>Branch: HEAD
>> > >>  >>
>> > >>  >>Copyright assignment: I am a RealNetworks employee.
>> > >>  >>
>> > >>  >>
>> > >>  >>Index: realplay_gtk_current.bif
>> > >>
>> > >>
>> > >>===================================================================
>> > >>  >>RCS file: /cvsroot/client/build/BIF/realplay_gtk_current.bif,v
>> > >>  >>retrieving revision 1.30
>> > >>  >>diff -u -w -r1.30 realplay_gtk_current.bif
>> > >>  >>--- realplay_gtk_current.bif    16 Sep 2005 01:42:37 -0000
>> > 1.30
>> > >>  >>+++ realplay_gtk_current.bif    26 Sep 2006 01:54:27 -0000
>> > >>  >>@@ -51,8 +51,8 @@
>> > >>  >>          datatype_mp3
>> > >>  >>          datatype_mp4
>> > >>  >>          datatype_mp4_audio_renderer
>> > >>  >>-        datatype_h263
>> > >>  >>          datatype_flash
>> > >>  >>+        datatype_aac_codec_helixaac
>> > >>  >>        
>> > >>  >>      
>> > >>  >>
>> > >>  >>
>> > >>  >>
>> > >>  >>
>> > >>  >>--
>> > >>  >>Daniel Yek
>> > >>
>
>
>_______________________________________________
>Player-dev mailing list
>Player-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/player-dev

Scott Nelson
Dir. Bus. Dev. Helix
www.helixcommunity.org
Office 925 838-5536  Mobile 925 890-5306

"The overall best 
codec was RealNetworks RealVideo."
StreamingMedia.com article by 
Jan Ozer  3/22/06


From dyek at real.com  Tue Oct  3 12:05:21 2006
From: dyek at real.com (Daniel Yek)
Date: Tue Oct  3 13:22:38 2006
Subject: [Player-dev] Adding datatype_aac_codec_helixaac to
	realplay_player_client_engine target
In-Reply-To: <6.2.3.4.2.20061003102916.026f8e90@mailone.real.com>
References: <019c01c6e1f7$5dc82f90$da8e17ac@D600HB>
	
	<000c01c6e32d$dd18a090$9749e1b0$@com>
	<6.2.1.2.2.20060929192628.236eaaf0@mailone.real.com>
	<6.2.3.4.2.20061003102916.026f8e90@mailone.real.com>
Message-ID: <6.2.1.2.2.20061003112225.21724180@mailone.real.com>

True! That is a helpful URL. It is easy to forget to look at the right place...

Now that I looked again, I found the source code. I must have been 
expecting something different and didn't look carefully in the sub-directories.

Everything seems to be done correctly, nonetheless. Let me know if it isn't so.

Thanks.


-- 
Daniel Yek


At 10:30 AM 10/3/2006, Scott Nelson wrote:
>Isn't there more info about AAC Fixed Point here?
>
>https://datatype.helixcommunity.org/2005/aacfixptdec
>
>Scott Nelson
>
>
>At 07:30 PM 9/29/2006, Daniel Yek wrote:
>
>>This AAC codec is from Coding Technology.
>>
>>This is the only clue that I can find:
>>
>>datatype/acc/codec/helixacc/platform/win/raac.rc:
>>VALUE "LegalCopyright",  HXVER_COPYRIGHT "and Coding Technologies"
>>
>>
>>We don't seem to have source code to this component, do we?
>>
>>
>> > The plan for Balto mentions adding the fixed-point cross-platform AAC
>> > codec under the Cayenne integration area.
>> > https://player.helixcommunity.org/2005/dev/plans.html
>>
>>That page actually says:
>>Open source, cross platform fixed point AAC code
>>
>>It doesn't seem like it is correct.
>>
>>
>>--
>>Daniel Yek
>>
>>
>>At 11:42 AM 9/28/2006, Haydon Boone wrote:
>>> > Would this be the Helix one or the CT one?
>>>
>>>Helix.
>>>
>>> > The plan for Balto mentions adding the fixed-point cross-platform
>>> > AAC codec under the Cayenne integration area.
>>>
>>>Right. And the codec team subsequently said that this was unnecessary.
>>>
>>> > Does our CT license cover Linux desktops?
>>>
>>>Yes, and I believe it's what is already in-use/shipping in current Linux RP
>>>10 builds.
>>>
>>> > -----Original Message-----
>>> > From: Donya Shirzad [mailto:dshirzad@real.com]
>>> > Sent: Wednesday, September 27, 2006 1:30 PM
>>> > To: hboone@real.com; 'Daniel Yek'; 'Player-dev'
>>> > Subject: RE: [Player-dev] CN-Client: Adding datatype_aac_codec_helixaac
>>> > to realplay_player_client_engine target
>>> >
>>> > The plan for Balto mentions adding the fixed-point cross-platform AAC
>>> > codec under the Cayenne integration area.  Would this be the Helix one
>>> > or the CT one?
>>> > https://player.helixcommunity.org/2005/dev/plans.html
>>> >
>>> > Does our CT license cover Linux desktops?
>>> >
>>> > Thanks,
>>> > - Donya
>>> >
>>> > At 10:39 PM -0700 9/26/06, Haydon Boone wrote:
>>> > >  Is this the RN-developed AAC implementation or the earlier AAC
>>> > >implementation that we licensed from Coding Technologies, prior to
>>> > >availability of the RN implementation?
>>> > >
>>> > >  Opinion expressed by our codec team was that, for at least the next
>>> > >version of the desktop RealPlayer products, there were not significant
>>> > >gains to be seen in moving away from the CT implementation, so we
>>> > >should continue to use it in these products for this next product
>>> > cycle...
>>> > >
>>> > >-/Haydon
>>> > >
>>> > >>  -----Original Message-----
>>> > >>  From: player-dev-bounces@helixcommunity.org
>>> > >>  [mailto:player-dev-bounces@helixcommunity.org] On Behalf Of Daniel
>>> > >> Yek
>>> > >>  Sent: Tuesday, September 26, 2006 5:49 PM
>>> > >>  To: Player-dev
>>> > >>  Subject: [Player-dev] CN-Client: Adding
>>> > datatype_aac_codec_helixaac
>>> > >> to realplay_player_client_engine target
>>> > >>
>>> > >>  Thanks, Bob.
>>> > >>
>>> > >>  This is now checked in.
>>> > >>
>>> > >>
>>> > >>  --
>>> > >>  Daniel Yek
>>> > >>
>>> > >>
>>> > >>  At 02:12 PM 9/26/2006, Bob Clark wrote:
>>> > >>  >Looks good, Daniel.
>>> > >>  >--Bob
>>> > >>  >
>>> > >>  >At 07:03 PM 9/25/2006, Daniel Yek wrote:
>>> > >>  >
>>> > >>  >>Modified by: dyek@real.com
>>> > >>  >>Date: 9/25/2006
>>> > >>  >>Project: Helix Player
>>> > >>  >>
>>> > >>  >>Synopsis: The HEAD branch of Linux RealPlayer was missing
>>> > >> components  >>needed to
>>> > >>  >>   play back raac content. This change includes the capability.
>>> > >>  >>
>>> > >>  >>Overview:
>>> > >>  >>   It is unclear to me whether datatype_aac_codec_helixaac
>>> > >>  was left out
>>> > >>  >>   intentionally or unintentionally.
>>> > >>  >>   I'm adding it now to the BIF files used by the HEAD branch.
>>> > >>  >>
>>> > >>  >>   datatype_h263 exists in hxplay_player_client_engine module
>>> > that
>>> > >>  >>   realplay_player_client_engine depends on, so it appears
>>> > >>  to be redundant
>>> > >>  >>   and removed:
>>> > >>  >>
>>> > >>  >>   >> > >>  type="name_only">
>>> > >>  >>     ...
>>> > >>  >>     
>>> > >>  >>     ...
>>> > >>  >>     datatype_h263
>>> > >>  >>     ...
>>> > >>  >>     
>>> > >>  >>   
>>> > >>  >>


From shafaq.abdullah at nokia.com  Wed Oct  4 15:01:51 2006
From: shafaq.abdullah at nokia.com (shafaq.abdullah@nokia.com)
Date: Wed Oct  4 16:16:59 2006
Subject: [Player-dev] Re: Moving image inside Window when using Xv
In-Reply-To: <451824D7.6080505@real.com>
Message-ID: <0E3F5E98557B914D9378E334A622A72501FDB5B3@esebe102.NOE.Nokia.com>

Hi,
   
>I guess I just don't know what you are trying to do that the 
>public site APIs can't do for you. Can you explain exactly 
>what your use case is?
I am using Public site API to set the position and size of the site. 
My currnet implementation is based on Minisite and  I am using Site
API's GetSize and GetPostion function to retreive the value earlier set.

However, I am not able to get the video output if I set the postion of
site something other than 0,0. There are no changes in the site code
other than setting and getting the site's position. 
Use case is simple: UI with fixed window, I try to move the video to
centre it with respect to aspect ratio. 

Any comments are welcomed.

Br,
S.Abdullah 

>-----Original Message-----
>From: player-dev-bounces@helixcommunity.org 
>[mailto:player-dev-bounces@helixcommunity.org] On Behalf Of 
>ext Greg Wright
>Sent: 25 September, 2006 21:50
>To: Abdullah Shafaq (Nokia-M/Helsinki)
>Cc: helix-client-dev@helixcommunity.org; 
>player-dev@lists.helixcommunity.org
>Subject: [Player-dev] Re: Moving image inside Window when using Xv
>
>shafaq.abdullah@nokia.com wrote:
>> Hi,
>>>    SetSize sets the size of the window, not the position. I do not 
>>> see any way to set the position of the site. The site is what 
>>> hxclientkit talks to in order to change the size/position/z-order 
>>> ect. of any visual presentation
>>   Thanks for the reply, I found it quite useful. Its true 
>that SetSize 
>> sets the size of window. However, I modified it so that its sets the 
>> position of window in addition to size.
>> SetSize(X, Y, width, height). Now Hxclient kit API in turn calls the 
>> IHXSite pointer's  setSize and GetSize method.
>> I just get the values of position and size from site before calling
>> XvShmPutImage() in video/sitelib/platform/unix/unixsurf.cpp. 
>> Although it is expected to work fine but what I came across 
>for video 
>> output as follows:
>> A constant green output from Xv while playing back any stream. 
>
>That is probably the color key. In debug mode the color key 
>changes depending on the bit-depth of your display:
>
>16 : red
>24 : green
>32 : blue.
>
>
>If you are seeing solid green my guess is that you are moving 
>the image out somewhere.
>
>>  If I switch to Full-Screen mode, I get the actual video output. 
>> SetSize method is called again and screen updated when video 
>output changes.
>> There seems to be some problem in updating the video output on Video 
>> drawing surface.
>> Is this a known problem in the Helix Framework 
>(hxclient_143_neptunex).
>> Any suggestions to avoid it and get the video output smoothly are 
>> appreciated.
>
>My guess is that it is because of your changes. You should not 
>move the site like you are unless you *really* know the site code well.
>
>Why can you not call SetPosition and SetSize in hxclientkit? 
>The site will know what to do.
>
>> 
>> Attempted Fix for the above problem:
>> I changed the CVideoRenderer::UpdateDisplay() in 
>> datatype/common/vidrend/vidrend.cpp
>> So that rDestRect = { windowPoint.x, 
>>                       windowPoint.y,
>>                       windowSize.cx, 
>>                       windowSize.cy };
>>    
>> Is changed to
>> 
>> rDestRect = { windowPoint.x, 
>>               windowPoint.y,
>>               windowPoint.x + windowSize.cx, 
>>               windowPoint.y + windowSize.cy };
>> 
>> Now the video image appears without showing green box but 
>actual video 
>> output is smaller than expected by X on horizontal and Y on vertical 
>> axis.
>
>Probably because you did not set the size of the site. Also if 
>you didn't change the source rect you now have the source and 
>destinations that are not the same aspect ratio.
>
>> And instead the video output contains green portion at the right and 
>> bottom edge respectively. The green portion inside video image is 
>> equal to X on horizontal and Y on vertical axis.
>> So final output dimensions = Video_width - x + x (Green portion), 
>> Video_Height - y + y (green).
>> 
>> Any help welcome and if something needs more explanation, please let 
>> me know.
>
>I guess I just don't know what you are trying to do that the 
>public site APIs can't do for you. Can you explain exactly 
>what your use case is?
>
>--greg.
>> 
>> Br,
>> Abdullah
>>    
>> 
>> 
>>> -----Original Message-----
>>> From: ext Greg Wright [mailto:gwright@real.com]
>>> Sent: 05 September, 2006 20:13
>>> To: Abdullah Shafaq (Nokia-M/Helsinki)
>>> Cc: rmathew@real.com; player-dev@lists.helixcommunity.org;
>>> helix-client-dev@helixcommunity.org
>>> Subject: Re: Moving image inside Window when using Xv
>>>
>>> shafaq.abdullah@nokia.com wrote:
>>>> Hi,
>>>>    I am using hxclient_143_neptunex on x86 platform (Linux Ubuntu
>>>> 2.6.15-26-386) . Using Xv for video rendering. 
>>>>
>>>> The problem with ClientPlayerSetSize is that Helix always 
>draws the 
>>>> image starting from the window, irrespective of the x,y 
>co-ordinates 
>>>> given to it.  i.e. if x=30 and y=30, image should appear at (30,30)
>>> SetSize sets the size of the window, not the position. I do not see 
>>> any way to set the position of the site. The site is what 
>hxclientkit 
>>> talks to in order to change the size/position/z-order ect. of any 
>>> visual presentation. The site (see 
>video/sitelib/basesite.cpp/.h) is 
>>> capable of all of this, it just looks like hxclientkit is 
>missing the 
>>> functions to let you change them. So, you can either add 
>the missing 
>>> functions or somehow get ahold of the IHXSite pointer 
>itself and call 
>>> all of the methods you need directly.
>>>
>>> See common/include/hxwin.h
>>>
>>> --greg.
>>>
>>>> inside window but its actual position starts from the left edge of 
>>>> window at (0,0) with respect to window.
>>>> One of the use case is to centre the image inside window 
>taking into 
>>>> account the ascpect ratio.
>>>> Is there anyway, I can draw the image on given co-ordinates x,y 
>>>> instead of image getting drawn starting from the left most
>>> edge of window?
>>>> Br,
>>>> S.Abdullah
>>>>
>>>>
>>>>
>> 
>
>_______________________________________________
>Player-dev mailing list
>Player-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/player-dev
>

From bobclark at real.com  Thu Oct  5 19:02:41 2006
From: bobclark at real.com (Bob Clark)
Date: Thu Oct  5 20:17:21 2006
Subject: [Player-dev] hxclientkit changes merge from head to 150Cay
Message-ID: <6.2.1.2.2.20061005185500.0372d520@mailone.real.com>

There have been a few changes made to hxclientkit on head that I'd like to 
pull over to 150Cay. This will ease the way for building Helix Player and 
RealPlayer on Linux using a 150Cay-tagged hxclientkit.


--Bob


Index: pub/HXClientCFuncs.h
===================================================================
RCS file: /cvsroot/player/hxclientkit/pub/HXClientCFuncs.h,v
retrieving revision 1.17.6.2
diff -u -w -r1.17.6.2 HXClientCFuncs.h
--- pub/HXClientCFuncs.h        22 Apr 2005 18:42:56 -0000      1.17.6.2
+++ pub/HXClientCFuncs.h        6 Oct 2006 01:52:08 -0000
@@ -113,6 +113,8 @@
  bool ClientPlayerGetGroupURL( HXClientPlayerToken clientPlayerToken, 
UInt16 groupIndex, char* pURLBuffer, UInt32 bufferLength, UInt32* 
pUsedBufferLength );
  bool ClientPlayerGetGroupTitle( HXClientPlayerToken clientPlayerToken, 
UInt16 groupIndex, char* pTitleBuffer, UInt32 bufferLength, UInt32* 
pUsedBufferLength );
  bool ClientPlayerSetCurrentGroup( HXClientPlayerToken clientPlayerToken, 
UInt16 groupIndex );
+bool ClientPlayerAppendGroup( HXClientPlayerToken clientPlayerToken, const 
char* pURLBuffer );
+void ClientPlayerRemoveGroup( HXClientPlayerToken clientPlayerToken, 
UInt16 groupIndex );
  void ClientPlayerDrawSite( HXClientPlayerToken clientPlayerToken, const 
SHXClientRect* pSiteRect );
  void ClientPlayerSetVolume( HXClientPlayerToken clientPlayerToken, UInt16 
volume );
  UInt16 ClientPlayerGetVolume( HXClientPlayerToken clientPlayerToken );

Index: src/CHXClientPlayer.cpp
===================================================================
RCS file: /cvsroot/player/hxclientkit/src/CHXClientPlayer.cpp,v
retrieving revision 1.35.2.2
diff -u -w -r1.35.2.2 CHXClientPlayer.cpp
--- src/CHXClientPlayer.cpp     22 Apr 2005 18:47:38 -0000      1.35.2.2
+++ src/CHXClientPlayer.cpp     6 Oct 2006 01:52:08 -0000
@@ -849,6 +849,50 @@
         return spGroupManager.IsValid() ? spGroupManager->SetCurrentGroup( 
groupIndex ) : HXR_FAIL;
  }

+bool
+CHXClientPlayer::AppendGroup( const char* pURLBuffer )
+{
+       SPIHXGroup spGroup;
+       SPIHXGroupManager spGroupManager = m_pIHXCorePlayer;
+
+       if ( spGroupManager.IsValid() && SUCCEEDED( 
spGroupManager->CreateGroup( *spGroup.AsInOutParam() ) ) && ( 
spGroup.IsValid() ) )
+       {
+               SPIHXValues spProperties = spGroup->GetGroupProperties();
+               if ( spProperties.IsValid() )
+               {
+                       SPIHXCommonClassFactory spCCF = m_pIHXCorePlayer;
+                       if ( spCCF.IsValid() )
+                       {
+                               HX_RESULT result = HXR_OK;
+                               SPIHXBuffer spBuffer( spCCF.Ptr(), 
CLSID_IHXBuffer, &result );
+                               if( spBuffer.IsValid() && SUCCEEDED( result ) )
+                               {
+                                       spBuffer->Set( (const UCHAR*) 
pURLBuffer, strlen( pURLBuffer ) + 1 );
+
+                                       spProperties->SetPropertyCString( 
"url", spBuffer.Ptr() );
+
+                                       if( SUCCEEDED( 
spGroupManager->AddGroup( spGroup.Ptr() ) ) )
+                                       {
+                                               return true;
+                                       }
+                               }
+                       }
+               }
+       }
+
+       return false;
+}
+
+void
+CHXClientPlayer::RemoveGroup( UINT16 groupIndex )
+{
+       SPIHXGroupManager spGroupManager = m_pIHXCorePlayer;
+       if ( spGroupManager.IsValid() )
+       {
+               spGroupManager->RemoveGroup( groupIndex );
+       }
+}
+
  static bool
  BufferContainsText( const SPIHXBuffer& spBuff )
  {

Index: src/CHXClientPlayer.h
===================================================================
RCS file: /cvsroot/player/hxclientkit/src/CHXClientPlayer.h,v
retrieving revision 1.19.6.2
diff -u -w -r1.19.6.2 CHXClientPlayer.h
--- src/CHXClientPlayer.h       22 Apr 2005 18:47:38 -0000      1.19.6.2
+++ src/CHXClientPlayer.h       6 Oct 2006 01:52:08 -0000
@@ -170,6 +170,8 @@
         virtual bool GetGroupURL( UINT16 groupIndex, char* pURLBuffer, 
UINT32 bufferLength, UINT32* pUsedBufferLength ) const;
         virtual bool GetGroupTitle( UINT16 groupIndex, char* pTitleBuffer, 
UINT32 bufferLength, UINT32* pUsedBufferLength ) const;
         virtual HX_RESULT SetCurrentGroup( UINT16 groupIndex );
+        virtual bool AppendGroup( const char* pURLBuffer );
+        virtual void RemoveGroup( UInt16 groupIndex );
         virtual void DrawSite( const HXxRect* pSiteRect );
         virtual void SetVolume( UINT16 volume );
         virtual UINT16 GetVolume( void ) const;

Index: src/HXClientCFuncs.cpp
===================================================================
RCS file: /cvsroot/player/hxclientkit/src/HXClientCFuncs.cpp,v
retrieving revision 1.19.6.3
diff -u -w -r1.19.6.3 HXClientCFuncs.cpp
--- src/HXClientCFuncs.cpp      15 Jul 2005 21:37:45 -0000      1.19.6.3
+++ src/HXClientCFuncs.cpp      6 Oct 2006 01:52:08 -0000
@@ -523,6 +523,39 @@
  }

  /*!
+  @function ClientPlayerAppendGroup
+  @param clientPlayerToken
+  @param pURLBuffer
+  @result true on success, false on fail
+  @abstract insert a group into the current presentation
+*/
+bool ClientPlayerAppendGroup( HXClientPlayerToken clientPlayerToken, const 
char* pURLBuffer )
+{
+       IHXClientPlayer* pIClientPlayer = ( IHXClientPlayer* ) 
clientPlayerToken;
+       if ( pIClientPlayer )
+       {
+               return pIClientPlayer->AppendGroup( pURLBuffer );
+       }
+       return false;
+}
+
+/*!
+  @function ClientPlayerRemoveGroup
+  @param clientPlayerToken
+  @param groupIndex
+  @result true on success, false on fail
+  @abstract skip to the specified group index
+*/
+void ClientPlayerRemoveGroup( HXClientPlayerToken clientPlayerToken, 
UInt16 groupIndex )
+{
+       IHXClientPlayer* pIClientPlayer = ( IHXClientPlayer* ) 
clientPlayerToken;
+       if( pIClientPlayer )
+        {
+                pIClientPlayer->RemoveGroup( groupIndex );
+        }
+}
+
+/*!
    @function ClientPlayerDrawSite
    @param clientPlayerToken
    @param pSiteRect

Index: src/IHXClientPlayer.h
===================================================================
RCS file: /cvsroot/player/hxclientkit/src/IHXClientPlayer.h,v
retrieving revision 1.14.6.2
diff -u -w -r1.14.6.2 IHXClientPlayer.h
--- src/IHXClientPlayer.h       22 Apr 2005 18:47:38 -0000      1.14.6.2
+++ src/IHXClientPlayer.h       6 Oct 2006 01:52:08 -0000
@@ -127,6 +127,8 @@
         virtual bool GetGroupURL( UINT16 groupIndex, char* pURLBuffer, 
UINT32 bufferLength, UINT32* pUsedBufferLength ) const = 0;
         virtual bool GetGroupTitle( UINT16 groupIndex, char* pTitleBuffer, 
UINT32 bufferLength, UINT32* pUsedBufferLength ) const = 0;
         virtual HX_RESULT SetCurrentGroup( UINT16 groupIndex ) = 0;
+        virtual bool AppendGroup( const char* pURLBuffer ) = 0;
+        virtual void RemoveGroup( UInt16 groupIndex ) = 0;
         virtual void DrawSite( const HXxRect* pSiteRect ) = 0;
         virtual void SetVolume( UINT16 volume ) = 0;
         virtual UINT16 GetVolume( void ) const = 0;




From bidh at midea.com.cn  Fri Oct  6 01:00:32 2006
From: bidh at midea.com.cn (BIDH)
Date: Fri Oct  6 02:15:28 2006
Subject: [Player-dev] a compile error
Message-ID: <002601c6e91d$7fbe0200$ed3c16ac@bidh>

Dear Greg,
        When I change my toolchain from arm-linux- to arm-none-linux-gnueabi- ,I met an error like below:
Entering directory '/usr/helix/common/system'
arm-none-linux-gnueabi-g++ -pipe -W -Wreturn-type -fno-exceptions -march=armv4t --permissive -fno-rtti -O0 -mabi-aapcs-linux -mfpu=vfp -mfloat-abi=softfp -g -DDEBUG -D_DEBUG -I../../common/runtime/pub -Ipub/platform/unix -I../include -I../container/pub -I../dbgtool/pub -I../util/pub -I../fileio/pub -I../runtime/pub -I./pub -I. -include armv4l-debg/common_system_ribodefs.h -fPIC -DPIC -o armv4l-dbg/obj/dllpath.o -c dllpath.cpp
{standard input}: Assembler messages:
{standard input}:36: Error: misaligned branch destination
{standard input}:78: Error: misaligned branch destination

Could you give me any suggestion to solve this problem?

Best Regards,
Daihui Bi

        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/player-dev/attachments/20061006/b96b5e30/attachment.html
From gwright at real.com  Fri Oct  6 11:00:36 2006
From: gwright at real.com (Greg Wright)
Date: Fri Oct  6 12:15:07 2006
Subject: [Player-dev] hxclientkit changes merge from head to 150Cay
In-Reply-To: <6.2.1.2.2.20061005185500.0372d520@mailone.real.com>
References: <6.2.1.2.2.20061005185500.0372d520@mailone.real.com>
Message-ID: <452699C4.2020701@real.com>

These look good to me.
--greg.


Bob Clark wrote:
> There have been a few changes made to hxclientkit on head that I'd like 
> to pull over to 150Cay. This will ease the way for building Helix Player 
> and RealPlayer on Linux using a 150Cay-tagged hxclientkit.
> 
> 
> --Bob
> 
> 
> Index: pub/HXClientCFuncs.h
> ===================================================================
> RCS file: /cvsroot/player/hxclientkit/pub/HXClientCFuncs.h,v
> retrieving revision 1.17.6.2
> diff -u -w -r1.17.6.2 HXClientCFuncs.h
> --- pub/HXClientCFuncs.h        22 Apr 2005 18:42:56 -0000      1.17.6.2
> +++ pub/HXClientCFuncs.h        6 Oct 2006 01:52:08 -0000
> @@ -113,6 +113,8 @@
>  bool ClientPlayerGetGroupURL( HXClientPlayerToken clientPlayerToken, 
> UInt16 groupIndex, char* pURLBuffer, UInt32 bufferLength, UInt32* 
> pUsedBufferLength );
>  bool ClientPlayerGetGroupTitle( HXClientPlayerToken clientPlayerToken, 
> UInt16 groupIndex, char* pTitleBuffer, UInt32 bufferLength, UInt32* 
> pUsedBufferLength );
>  bool ClientPlayerSetCurrentGroup( HXClientPlayerToken 
> clientPlayerToken, UInt16 groupIndex );
> +bool ClientPlayerAppendGroup( HXClientPlayerToken clientPlayerToken, 
> const char* pURLBuffer );
> +void ClientPlayerRemoveGroup( HXClientPlayerToken clientPlayerToken, 
> UInt16 groupIndex );
>  void ClientPlayerDrawSite( HXClientPlayerToken clientPlayerToken, const 
> SHXClientRect* pSiteRect );
>  void ClientPlayerSetVolume( HXClientPlayerToken clientPlayerToken, 
> UInt16 volume );
>  UInt16 ClientPlayerGetVolume( HXClientPlayerToken clientPlayerToken );
> 
> Index: src/CHXClientPlayer.cpp
> ===================================================================
> RCS file: /cvsroot/player/hxclientkit/src/CHXClientPlayer.cpp,v
> retrieving revision 1.35.2.2
> diff -u -w -r1.35.2.2 CHXClientPlayer.cpp
> --- src/CHXClientPlayer.cpp     22 Apr 2005 18:47:38 -0000      1.35.2.2
> +++ src/CHXClientPlayer.cpp     6 Oct 2006 01:52:08 -0000
> @@ -849,6 +849,50 @@
>         return spGroupManager.IsValid() ? 
> spGroupManager->SetCurrentGroup( groupIndex ) : HXR_FAIL;
>  }
> 
> +bool
> +CHXClientPlayer::AppendGroup( const char* pURLBuffer )
> +{
> +       SPIHXGroup spGroup;
> +       SPIHXGroupManager spGroupManager = m_pIHXCorePlayer;
> +
> +       if ( spGroupManager.IsValid() && SUCCEEDED( 
> spGroupManager->CreateGroup( *spGroup.AsInOutParam() ) ) && ( 
> spGroup.IsValid() ) )
> +       {
> +               SPIHXValues spProperties = spGroup->GetGroupProperties();
> +               if ( spProperties.IsValid() )
> +               {
> +                       SPIHXCommonClassFactory spCCF = m_pIHXCorePlayer;
> +                       if ( spCCF.IsValid() )
> +                       {
> +                               HX_RESULT result = HXR_OK;
> +                               SPIHXBuffer spBuffer( spCCF.Ptr(), 
> CLSID_IHXBuffer, &result );
> +                               if( spBuffer.IsValid() && SUCCEEDED( 
> result ) )
> +                               {
> +                                       spBuffer->Set( (const UCHAR*) 
> pURLBuffer, strlen( pURLBuffer ) + 1 );
> +
> +                                       
> spProperties->SetPropertyCString( "url", spBuffer.Ptr() );
> +
> +                                       if( SUCCEEDED( 
> spGroupManager->AddGroup( spGroup.Ptr() ) ) )
> +                                       {
> +                                               return true;
> +                                       }
> +                               }
> +                       }
> +               }
> +       }
> +
> +       return false;
> +}
> +
> +void
> +CHXClientPlayer::RemoveGroup( UINT16 groupIndex )
> +{
> +       SPIHXGroupManager spGroupManager = m_pIHXCorePlayer;
> +       if ( spGroupManager.IsValid() )
> +       {
> +               spGroupManager->RemoveGroup( groupIndex );
> +       }
> +}
> +
>  static bool
>  BufferContainsText( const SPIHXBuffer& spBuff )
>  {
> 
> Index: src/CHXClientPlayer.h
> ===================================================================
> RCS file: /cvsroot/player/hxclientkit/src/CHXClientPlayer.h,v
> retrieving revision 1.19.6.2
> diff -u -w -r1.19.6.2 CHXClientPlayer.h
> --- src/CHXClientPlayer.h       22 Apr 2005 18:47:38 -0000      1.19.6.2
> +++ src/CHXClientPlayer.h       6 Oct 2006 01:52:08 -0000
> @@ -170,6 +170,8 @@
>         virtual bool GetGroupURL( UINT16 groupIndex, char* pURLBuffer, 
> UINT32 bufferLength, UINT32* pUsedBufferLength ) const;
>         virtual bool GetGroupTitle( UINT16 groupIndex, char* 
> pTitleBuffer, UINT32 bufferLength, UINT32* pUsedBufferLength ) const;
>         virtual HX_RESULT SetCurrentGroup( UINT16 groupIndex );
> +        virtual bool AppendGroup( const char* pURLBuffer );
> +        virtual void RemoveGroup( UInt16 groupIndex );
>         virtual void DrawSite( const HXxRect* pSiteRect );
>         virtual void SetVolume( UINT16 volume );
>         virtual UINT16 GetVolume( void ) const;
> 
> Index: src/HXClientCFuncs.cpp
> ===================================================================
> RCS file: /cvsroot/player/hxclientkit/src/HXClientCFuncs.cpp,v
> retrieving revision 1.19.6.3
> diff -u -w -r1.19.6.3 HXClientCFuncs.cpp
> --- src/HXClientCFuncs.cpp      15 Jul 2005 21:37:45 -0000      1.19.6.3
> +++ src/HXClientCFuncs.cpp      6 Oct 2006 01:52:08 -0000
> @@ -523,6 +523,39 @@
>  }
> 
>  /*!
> +  @function ClientPlayerAppendGroup
> +  @param clientPlayerToken
> +  @param pURLBuffer
> +  @result true on success, false on fail
> +  @abstract insert a group into the current presentation
> +*/
> +bool ClientPlayerAppendGroup( HXClientPlayerToken clientPlayerToken, 
> const char* pURLBuffer )
> +{
> +       IHXClientPlayer* pIClientPlayer = ( IHXClientPlayer* ) 
> clientPlayerToken;
> +       if ( pIClientPlayer )
> +       {
> +               return pIClientPlayer->AppendGroup( pURLBuffer );
> +       }
> +       return false;
> +}
> +
> +/*!
> +  @function ClientPlayerRemoveGroup
> +  @param clientPlayerToken
> +  @param groupIndex
> +  @result true on success, false on fail
> +  @abstract skip to the specified group index
> +*/
> +void ClientPlayerRemoveGroup( HXClientPlayerToken clientPlayerToken, 
> UInt16 groupIndex )
> +{
> +       IHXClientPlayer* pIClientPlayer = ( IHXClientPlayer* ) 
> clientPlayerToken;
> +       if( pIClientPlayer )
> +        {
> +                pIClientPlayer->RemoveGroup( groupIndex );
> +        }
> +}
> +
> +/*!
>    @function ClientPlayerDrawSite
>    @param clientPlayerToken
>    @param pSiteRect
> 
> Index: src/IHXClientPlayer.h
> ===================================================================
> RCS file: /cvsroot/player/hxclientkit/src/IHXClientPlayer.h,v
> retrieving revision 1.14.6.2
> diff -u -w -r1.14.6.2 IHXClientPlayer.h
> --- src/IHXClientPlayer.h       22 Apr 2005 18:47:38 -0000      1.14.6.2
> +++ src/IHXClientPlayer.h       6 Oct 2006 01:52:08 -0000
> @@ -127,6 +127,8 @@
>         virtual bool GetGroupURL( UINT16 groupIndex, char* pURLBuffer, 
> UINT32 bufferLength, UINT32* pUsedBufferLength ) const = 0;
>         virtual bool GetGroupTitle( UINT16 groupIndex, char* 
> pTitleBuffer, UINT32 bufferLength, UINT32* pUsedBufferLength ) const = 0;
>         virtual HX_RESULT SetCurrentGroup( UINT16 groupIndex ) = 0;
> +        virtual bool AppendGroup( const char* pURLBuffer ) = 0;
> +        virtual void RemoveGroup( UInt16 groupIndex ) = 0;
>         virtual void DrawSite( const HXxRect* pSiteRect ) = 0;
>         virtual void SetVolume( UINT16 volume ) = 0;
>         virtual UINT16 GetVolume( void ) const = 0;
> 
> 
> 
> 
> _______________________________________________
> Player-dev mailing list
> Player-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/player-dev
> 

From gwright at real.com  Fri Oct  6 11:03:05 2006
From: gwright at real.com (Greg Wright)
Date: Fri Oct  6 12:17:36 2006
Subject: [Player-dev] Re: a compile error
In-Reply-To: <002601c6e91d$7fbe0200$ed3c16ac@bidh>
References: <002601c6e91d$7fbe0200$ed3c16ac@bidh>
Message-ID: <45269A59.1080709@real.com>

BIDH wrote:
> Dear Greg,
>         When I change my toolchain from arm-linux- to arm-none-linux-gnueabi- ,I met an error like below:
> Entering directory '/usr/helix/common/system'
> arm-none-linux-gnueabi-g++ -pipe -W -Wreturn-type -fno-exceptions -march=armv4t --permissive -fno-rtti -O0 -mabi-aapcs-linux -mfpu=vfp -mfloat-abi=softfp -g -DDEBUG -D_DEBUG -I../../common/runtime/pub -Ipub/platform/unix -I../include -I../container/pub -I../dbgtool/pub -I../util/pub -I../fileio/pub -I../runtime/pub -I./pub -I. -include armv4l-debg/common_system_ribodefs.h -fPIC -DPIC -o armv4l-dbg/obj/dllpath.o -c dllpath.cpp
> {standard input}: Assembler messages:
> {standard input}:36: Error: misaligned branch destination
> {standard input}:78: Error: misaligned branch destination
> 
> Could you give me any suggestion to solve this problem?

I really have no idea. I have not used "arm-none-linux-gnueabi-*" before.

But, it looks like you need to tweak your compiler flags perhaps.
Either way, g++ is outputing bad ASM or ASM that is not correct
for your platform.

--greg.

> 
> Best Regards,
> Daihui Bi
> 
>         

From dyek at real.com  Fri Oct  6 14:12:19 2006
From: dyek at real.com (Daniel Yek)
Date: Fri Oct  6 15:24:48 2006
Subject: [Player-dev] CR-Client: Copy from
 datatype_rn/flash/renderer/dbg/swf* if they exist.
Message-ID: <6.2.1.2.2.20061006141030.4351c088@mailone.real.com>


Modified by: dyek@real.com
Date: 10/5/2006
Project: Helix Player

Synopsis: Copy from datatype_rn/flash/renderer/dbg/swf* if they exist.

Overview:
   When building from source, Flash binaries ended up in a different directory
   and hence missing from the installer.
   This custom code in the makefile specifically look for the directory.
   This is similar to other code in the make file.
   Let me know if Ribosome supports this operation without writing this custom
   code.

   This checkin also removed the HelixPlayer/lib directory which is now empty.
   It contained libgtkhx.so / libgtkhxplay.so (The Helix GTK+ Widget) earlier.

Files Modified:
player/installer/archive/make_tempdir

Platforms and Profiles Build Verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Platforms and Profiles Functionality verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Branch: HEAD

Copyright assignment: I am a RealNetworks employee.


Index: make_tempdir
===================================================================
RCS file: /cvsroot/player/installer/archive/make_tempdir,v
retrieving revision 1.68
diff -u -w -r1.68 make_tempdir
--- make_tempdir        15 Sep 2006 19:46:54 -0000      1.68
+++ make_tempdir        6 Oct 2006 05:01:36 -0000
@@ -68,7 +68,7 @@
          "plugins",
          "share",
          "doc",
-        "lib",
+        #"lib",  # Used by libgtkhxplay(.so) only.
          "mozilla",
          "postinst")

@@ -323,6 +323,11 @@

  # Flash support
  if project.IsDefined("HELIX_FEATURE_FLASH"):
+    if os.path.exists(os.path.join(project.src_root_path, "datatype_rn", 
"flash", "renderer", project.output_dir, "swfrender.so")):
+        inst.CopyModuleDlls(
+            ("datatype_rn/flash/renderer", "swfrender", "plugins/swfrender"),
+            ("datatype_rn/flash/fileformat", "swfformat", 
"plugins/swfformat"))
+    else:
      inst.CopyModuleDlls(
          ("datatype/flash/renderer", "swfrender", "plugins/swfrender"),
          ("datatype/flash/fileformat", "swfformat", "plugins/swfformat"))



-- 
Daniel Yek


From mats.larsson at ericsson.com  Tue Oct 10 06:56:41 2006
From: mats.larsson at ericsson.com (Mats Larsson)
Date: Tue Oct 10 08:11:01 2006
Subject: [Player-dev] RealPlayer 10.0.8 and Helix Player 1.0.8 update
	forFirefox 1.5 API changes
In-Reply-To: <44EC579B.8070507@sun.com>
References: <44EC579B.8070507@sun.com>
Message-ID: <452BA699.7070000@ericsson.com>

On 2006-08-23 15:26, jerry tan wrote:
> Daniel Yek wrote:

>  > RealPlayer 10.0.8 and Helix Player 1.0.8 for Linux are now available.
>  > It is an update for Firefox 1.5 API changes.
>  >
>  > You can download Helix Player 1.0.8 from:
>  > https://player.helixcommunity.org/
>  >
>  > You can download RealPlayer 10.0.8 from:
>  > http://www.real.com/linux
>  >
>  >
>  >
> Realplayer 10.0.8 for solaris will be released soon also.

Hi Jerry,

When is soon?

BR MOL

From Jerry.Tan at Sun.COM  Tue Oct 10 18:49:33 2006
From: Jerry.Tan at Sun.COM (Jerry Tan)
Date: Tue Oct 10 20:22:32 2006
Subject: [Player-dev] RealPlayer 10.0.8 and Helix Player 1.0.8 update
	forFirefox 1.5 API changes
In-Reply-To: <452BA699.7070000@ericsson.com>
References: <44EC579B.8070507@sun.com> <452BA699.7070000@ericsson.com>
Message-ID: <452C4DAD.7040309@sun.com>

The patch will be committed in branch in 2 weeks, plus some other minor 
patches.
then 10.0.8 on solaris will be available for download.



Mats Larsson wrote:
> On 2006-08-23 15:26, jerry tan wrote:
>> Daniel Yek wrote:
>
>>  > RealPlayer 10.0.8 and Helix Player 1.0.8 for Linux are now available.
>>  > It is an update for Firefox 1.5 API changes.
>>  >
>>  > You can download Helix Player 1.0.8 from:
>>  > https://player.helixcommunity.org/
>>  >
>>  > You can download RealPlayer 10.0.8 from:
>>  > http://www.real.com/linux
>>  >
>>  >
>>  >
>> Realplayer 10.0.8 for solaris will be released soon also.
>
> Hi Jerry,
>
> When is soon?
>
> BR MOL
>
> _______________________________________________
> Player-dev mailing list
> Player-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/player-dev


From sunnnnyday at yahoo.com  Wed Oct 11 11:01:18 2006
From: sunnnnyday at yahoo.com (sunny day)
Date: Wed Oct 11 12:14:41 2006
Subject: [Player-dev] plugin for real player windows
Message-ID: <20061011180119.80425.qmail@web34314.mail.mud.yahoo.com>


					Hi all,



I'm trying to write a plugin for real player windows. I could not find
any docs on this. Can anyone point out where should I start?



I downloaded the source from nightly build (due to I have some problem
connect with Helix cvs server), I could not find any samples in the
source. 



Any input will be appreciated,



-Cecilia


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/player-dev/attachments/20061011/73609baa/attachment-0001.html
From jeffa at real.com  Wed Oct 11 11:55:35 2006
From: jeffa at real.com (Jeff Ayars)
Date: Wed Oct 11 13:08:59 2006
Subject: [Player-dev] plugin for real player windows
In-Reply-To: <20061011180119.80425.qmail@web34314.mail.mud.yahoo.com>
References: <20061011180119.80425.qmail@web34314.mail.mud.yahoo.com>
Message-ID: <6.2.1.2.2.20061011115100.026ad430@mailone.real.com>

Docs are here:

https://common.helixcommunity.org/nonav/2003/HCS_SDK_r5/helixsdk.htm

The "sdk" is in /common/hcs_sdk/wip/helixsdk_r5.zip

JEff

At 11:01 AM 10/11/2006, sunny day wrote:
>Hi all,
>
>I'm trying to write a plugin for real player windows. I could not find any 
>docs on this. Can anyone point out where should I start?
>
>I downloaded the source from nightly build (due to I have some problem 
>connect with Helix cvs server), I could not find any samples in the source.
>
>Any input will be appreciated,
>
>-Cecilia
>
>_______________________________________________
>Player-dev mailing list
>Player-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/player-dev


From sunnnnyday at yahoo.com  Wed Oct 11 15:08:29 2006
From: sunnnnyday at yahoo.com (sunny day)
Date: Wed Oct 11 16:21:48 2006
Subject: [Player-dev] error when building realplayer source
Message-ID: <20061011220829.10777.qmail@web34311.mail.mud.yahoo.com>

Hi all,

I downloaded the source code of realplayer. I got the following error message when I try to do the build by using the Makefile or the make.bat file:


getting files
[#-00000160][2006-10-11 12:01:06][172][INFO ] : Checking out source code and binary distributions.
Group size: 1  Modules: 0  Threads: 2
[#-00000166][2006-10-11 12:01:06][172][INFO ] : Enabling threading, 2 threads requested.
[#-00000168][2006-10-11 12:01:06][172][INFO ] : Starting thread scheduler to process jobs.
[#-00000172][2006-10-11 12:01:06][172][INFO ] : Thread scheduler run completed.

Checkout done in 00:12
compiling
registrating...
modulating...
[#-00000178][2006-10-11 12:01:19][172][INFO ] : Prioritizing module list.
Umake warning: Module does not exist in BIF file.
signing output binaries
Build Complete: Wed Oct 11 12:01:21 2006
copy path="debug" not found
/HelixSDK/build\lib\buildapp.py:1307: DeprecationWarning: raising a string exception is deprecated
  raise err.error, e
[#-00000224][2006-10-11 12:01:21][172][ERROR] : --- Build System Error ------------------------------------
You have found a Ribosome bug.
-----------------------------------------------------------
--- Python Traceback --------------------------------------
------------------------------------
Traceback (most recent call last):
  File "C:\HelixSDK\build\bin\launcher.py", line 117, in __runTool
    tool.run()
  File "/HelixSDK/build\lib\build_exe.py", line 893, in run
    command_line_args()
  File "/HelixSDK/build\lib\build_exe.py", line 156, in command_line_args
    invoke_buildsystem(arg_list)
  File "/HelixSDK/build\lib\build_exe.py", line 111, in invoke_buildsystem
    app = buildapp.RunBuild(arg_list)
  File "/HelixSDK/build\lib\buildapp.py", line 102, in RunBuild
    app.main()
  File "/HelixSDK/build\lib\buildapp.py", line 196, in main
    self.run()
  File "/HelixSDK/build\lib\buildapp.py", line 400, in run
    self.sign()
  File "/HelixSDK/build\lib\buildapp.py", line 1307, in sign
    raise err.error, e
Build System Error: Cannot list directory="debug".
-----------------------------------------------------------

C:\HelixSDK\build\bin\launcher.py:131: DeprecationWarning: raising a string exception is deprecated
  raise
Traceback (most recent call last):
  File "build/bin/build.py", line 67, in 
    tool.run()
  File "C:\HelixSDK\build\bin\launcher.py", line 97, in run
    self.__runTool()
  File "C:\HelixSDK\build\bin\launcher.py", line 117, in __runTool
    tool.run()
  File "/HelixSDK/build\lib\build_exe.py", line 893, in run
    command_line_args()
  File "/HelixSDK/build\lib\build_exe.py", line 156, in command_line_args
    invoke_buildsystem(arg_list)
  File "/HelixSDK/build\lib\build_exe.py", line 111, in invoke_buildsystem
    app = buildapp.RunBuild(arg_list)
  File "/HelixSDK/build\lib\buildapp.py", line 102, in RunBuild
    app.main()
  File "/HelixSDK/build\lib\buildapp.py", line 196, in main
    self.run()
  File "/HelixSDK/build\lib\buildapp.py", line 400, in run
    self.sign()
  File "/HelixSDK/build\lib\buildapp.py", line 1307, in sign
    raise err.error, e
Build System Error: Cannot list directory="debug".
make: *** [all] Error 1


Thanks for your attention,

-Cecilia



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/player-dev/attachments/20061011/40eefa52/attachment.html
From dyek at real.com  Wed Oct 11 15:25:56 2006
From: dyek at real.com (Daniel Yek)
Date: Wed Oct 11 16:37:11 2006
Subject: [Player-dev] error when building realplayer source
In-Reply-To: <20061011220829.10777.qmail@web34311.mail.mud.yahoo.com>
References: <20061011220829.10777.qmail@web34311.mail.mud.yahoo.com>
Message-ID: <6.2.1.2.2.20061011151357.26e8b120@mailone.real.com>

Hi Cecilia,

I would rather you use Ribosome to check out source code from CVS and build 
it from there. There are distribution binaries that will only be available 
to you after you signed the Binary EULA (BEULA); that is needed to build 
RealPlayer, but not needed for the Open Source Helix Player.

Quick Starts:
https://common.helixcommunity.org/2004/devdocs/quickstart
https://player.helixcommunity.org/2005/dev/quickstart.html

What is the problem when you build from CVS?

Could you follow the Quick Start closely and not deviate from it before you 
have your first success in building the player? That would help a lot. Some 
CVS/SSH access problem would resolve in a day or less. So, it would help to 
keep trying a bit.

Thanks.


-- 
Daniel Yek


At 03:08 PM 10/11/2006, sunny day wrote:
>Hi all,
>
>I downloaded the source code of realplayer. I got the following error 
>message when I try to do the build by using the Makefile or the make.bat file:
>
>
>getting files
>[#-00000160][2006-10-11 12:01:06][172][INFO ] : Checking out source code 
>and binary distributions.
>Group size: 1  Modules: 0  Threads: 2
>[#-00000166][2006-10-11 12:01:06][172][INFO ] : Enabling threading, 2 
>threads requested.
>[#-00000168][2006-10-11 12:01:06][172][INFO ] : Starting thread scheduler 
>to process jobs.
>[#-00000172][2006-10-11 12:01:06][172][INFO ] : Thread scheduler run 
>completed.
>
>Checkout done in 00:12
>compiling
>registrating...
>modulating...
>[#-00000178][2006-10-11 12:01:19][172][INFO ] : Prioritizing module list.
>Umake warning: Module does not exist in BIF file.
>signing output binaries
>Build Complete: Wed Oct 11 12:01:21 2006
>copy path="debug" not found
>/HelixSDK/build\lib\buildapp.py:1307: DeprecationWarning: raising a string 
>exception is deprecated
>   raise err.error, e
>[#-00000224][2006-10-11 12:01:21][172][ERROR] : --- Build System Error 
>------------------------------------
>You have found a Ribosome bug.
>-----------------------------------------------------------
>--- Python Traceback --------------------------------------
>------------------------------------
>Traceback (most recent call last):
>   File "C:\HelixSDK\build\bin\launcher.py", line 117, in __runTool
>     tool.run()
>   File "/HelixSDK/build\lib\build_exe.py", line 893, in run
>     command_line_args()
>   File "/HelixSDK/build\lib\build_exe.py", line 156, in command_line_args
>     invoke_buildsystem(arg_list)
>   File "/HelixSDK/build\lib\build_exe.py", line 111, in invoke_buildsystem
>     app = buildapp.RunBuild(arg_list)
>   File "/HelixSDK/build\lib\buildapp.py", line 102, in RunBuild
>     app.main()
>   File "/HelixSDK/build\lib\buildapp.py", line 196, in main
>     self.run()
>   File "/HelixSDK/build\lib\buildapp.py", line 400, in run
>     self.sign()
>   File "/HelixSDK/build\lib\buildapp.py", line 1307, in sign
>     raise err.error, e
>Build System Error: Cannot list directory="debug".
>-----------------------------------------------------------
>
>C:\HelixSDK\build\bin\launcher.py:131: DeprecationWarning: raising a 
>string exception is deprecated
>   raise
>Traceback (most recent call last):
>   File "build/bin/build.py", line 67, in 
>     tool.run()
>   File "C:\HelixSDK\build\bin\launcher.py", line 97, in run
>     self.__runTool()
>   File "C:\HelixSDK\build\bin\launcher.py", line 117, in __runTool
>     tool.run()
>   File "/HelixSDK/build\lib\build_exe.py", line 893, in run
>     command_line_args()
>   File "/HelixSDK/build\lib\build_exe.py", line 156, in command_line_args
>     invoke_buildsystem(arg_list)
>   File "/HelixSDK/build\lib\build_exe.py", line 111, in invoke_buildsystem
>     app = buildapp.RunBuild(arg_list)
>   File "/HelixSDK/build\lib\buildapp.py", line 102, in RunBuild
>     app.main()
>   File "/HelixSDK/build\lib\buildapp.py", line 196, in main
>     self.run()
>   File "/HelixSDK/build\lib\buildapp.py", line 400, in run
>     self.sign()
>   File "/HelixSDK/build\lib\buildapp.py", line 1307, in sign
>     raise err.error, e
>Build System Error: Cannot list directory="debug".
>make: *** [all] Error 1
>
>
>Thanks for your attention,
>
>-Cecilia


From dyek at real.com  Wed Oct 11 16:00:56 2006
From: dyek at real.com (Daniel Yek)
Date: Wed Oct 11 17:12:11 2006
Subject: [Player-dev] error when building realplayer source
In-Reply-To: <20061011223109.48980.qmail@web34305.mail.mud.yahoo.com>
References: <20061011223109.48980.qmail@web34305.mail.mud.yahoo.com>
Message-ID: <6.2.1.2.2.20061011153819.2ae87538@mailone.real.com>

At 03:31 PM 10/11/2006, sunny day wrote:
>Thanks Daniel,
>
>I wanted to check the source out from your cvs server. I followed the 
>step-by-step instruction on the web, and generated the rsa pub key and put 
>it into my account days ago. I still cannot connect to the cvs server, I 
>got the following error:
>
>OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
>debug2: ssh_connect: needpriv 0
>debug1: Connecting to cvs.helixcommunity.org [207.188.25.137] port 22.
>debug1: connect to address 207.188.25.137 port 22: Connection timed out
>ssh: connect to host cvs.helixcommunity.org port 22: Connection timed out

What ssh command line did you use?

I can collect to the same server, so it is not down.

What happened when you type in the following command?
ssh -v -l yourid cvs.helixcommunity.org

If "ssh -l yourid cvs.helixcommunity.org" doesn't complete without entering 
your password manually, you might have not completed setting up your CVS 
access. If you are sure that you have done the steps, then the Helix 
Community admin should look into the problem.


>That's why I downloaded the source from your nightly build.
>
>Another question: I'm trying to get the hello_world sample. Since I cannot 
>connect to the cvs server, I tried to download from the cvs tree on your 
>web, but I saw HTTP 500 error. Do you know if there is another way I can 
>get the hello_world sample?

Where did you get the information about the "hello_world" sample?

You can access individual CVS repository from individual project sites; for 
example, from the player (the GUI on top of Helix Client) project page, and 
the Helix Client page:

https://player.helixcommunity.org/
https://helix-client.helixcommunity.org/

you can find the CVS links toward the bottom of the right hand column to 
the repositories:
https://helixcommunity.org/plugins/scmcvs/cvsweb.php/?cvsroot=player
https://helixcommunity.org/plugins/scmcvs/cvsweb.php/?cvsroot=helix-client



-- 
Daniel Yek


>Thanks much,
>
>-Cecilia
>----- Original Message ----
>From: Daniel Yek 
>To: sunny day ; player-dev@helixcommunity.org
>Sent: Wednesday, October 11, 2006 3:25:56 PM
>Subject: Re: [Player-dev] error when building realplayer source
>
>Hi Cecilia,
>
>I would rather you use Ribosome to check out source code from CVS and build
>it from there. There are distribution binaries that will only be available
>to you after you signed the Binary EULA (BEULA); that is needed to build
>RealPlayer, but not needed for the Open Source Helix Player.
>
>Quick Starts:
>https://common.helixcommunity.org/2004/devdocs/quickstart
>https://player.helixcommunity.org/2005/dev/quickstart.html
>
>What is the problem when you build from CVS?
>
>Could you follow the Quick Start closely and not deviate from it before you
>have your first success in building the player? That would help a lot. Some
>CVS/SSH access problem would resolve in a day or less. So, it would help to
>keep trying a bit.
>
>Thanks.
>
>
>--
>Daniel Yek
>
>
>At 03:08 PM 10/11/2006, sunny day wrote:
> >Hi all,
> >
> >I downloaded the source code of realplayer. I got the following error
> >message when I try to do the build by using the Makefile or the make.bat 
> file:
> >
> >
> >getting files
> >[#-00000160][2006-10-11 12:01:06][172][INFO ] : Checking out source code
> >and binary distributions.
> >Group size: 1  Modules: 0  Threads: 2
> >[#-00000166][2006-10-11 12:01:06][172][INFO ] : Enabling threading, 2
> >threads requested.
> >[#-00000168][2006-10-11 12:01:06][172][INFO ] : Starting thread scheduler
> >to process jobs.
> >[#-00000172][2006-10-11 12:01:06][172][INFO ] : Thread scheduler run
> >completed.
> >
> >Checkout done in 00:12
> >compiling
> >registrating...
> >modulating...
> >[#-00000178][2006-10-11 12:01:19][172][INFO ] : Prioritizing module list.
> >Umake warning: Module does not exist in BIF file.
> >signing output binaries
> >Build Complete: Wed Oct 11 12:01:21 2006
> >copy path="debug" not found
> >/HelixSDK/build\lib\buildapp.py:1307: DeprecationWarning: raising a string
> >exception is deprecated
> >   raise err.error, e
> >[#-00000224][2006-10-11 12:01:21][172][ERROR] : --- Build System Error
> >------------------------------------
> >You have found a Ribosome bug.
> >-----------------------------------------------------------
> >--- Python Traceback --------------------------------------
> >------------------------------------
> >Traceback (most recent call last):
> >   File "C:\HelixSDK\build\bin\launcher.py", line 117, in __runTool
> >     tool.run()
> >   File "/HelixSDK/build\lib\build_exe.py", line 893, in run
> >     command_line_args()
> >   File "/HelixSDK/build\lib\build_exe.py", line 156, in command_line_args
> >     invoke_buildsystem(arg_list)
> >   File "/HelixSDK/build\lib\build_exe.py", line 111, in invoke_buildsystem
> >     app = buildapp.RunBuild(arg_list)
> >   File "/HelixSDK/build\lib\buildapp.py", line 102, in RunBuild
> >     app.main()
> >   File "/HelixSDK/build\lib\buildapp.py", line 196, in main
> >     self.run()
> >   File "/HelixSDK/build\lib\buildapp.py", line 400, in run
> >     self.sign()
> >   File "/HelixSDK/build\lib\buildapp.py", line 1307, in sign
> >     raise err.error, e
> >Build System Error: Cannot list directory="debug".
> >-----------------------------------------------------------
> >
> >C:\HelixSDK\build\bin\launcher.py:131: DeprecationWarning: raising a
> >string exception is deprecated
> >   raise
> >Traceback (most recent call last):
> >   File "build/bin/build.py", line 67, in 
> >     tool.run()
> >   File "C:\HelixSDK\build\bin\launcher.py", line 97, in run
> >     self.__runTool()
> >   File "C:\HelixSDK\build\bin\launcher.py", line 117, in __runTool
> >     tool.run()
> >   File "/HelixSDK/build\lib\build_exe.py", line 893, in run
> >     command_line_args()
> >   File "/HelixSDK/build\lib\build_exe.py", line 156, in command_line_args
> >     invoke_buildsystem(arg_list)
> >   File "/HelixSDK/build\lib\build_exe.py", line 111, in invoke_buildsystem
> >     app = buildapp.RunBuild(arg_list)
> >   File "/HelixSDK/build\lib\buildapp.py", line 102, in RunBuild
> >     app.main()
> >   File "/HelixSDK/build\lib\buildapp.py", line 196, in main
> >     self.run()
> >   File "/HelixSDK/build\lib\buildapp.py", line 400, in run
> >     self.sign()
> >   File "/HelixSDK/build\lib\buildapp.py", line 1307, in sign
> >     raise err.error, e
> >Build System Error: Cannot list directory="debug".
> >make: *** [all] Error 1
> >
> >
> >Thanks for your attention,
> >
> >-Cecilia
>
>


From kliu at real.com  Wed Oct 11 16:05:20 2006
From: kliu at real.com (Kinson Liu)
Date: Wed Oct 11 17:18:35 2006
Subject: [Player-dev] error when building realplayer source
In-Reply-To: <6.2.1.2.2.20061011153819.2ae87538@mailone.real.com>
References: <20061011223109.48980.qmail@web34305.mail.mud.yahoo.com>
	<6.2.1.2.2.20061011153819.2ae87538@mailone.real.com>
Message-ID: <452D78B0.3060201@real.com>

Daniel,

I am afraid it's firewall problem. We are currently working on a 
get-around on this. Thanks for replying.

Kinson

Daniel Yek wrote:
> At 03:31 PM 10/11/2006, sunny day wrote:
>> Thanks Daniel,
>>
>> I wanted to check the source out from your cvs server. I followed the 
>> step-by-step instruction on the web, and generated the rsa pub key 
>> and put it into my account days ago. I still cannot connect to the 
>> cvs server, I got the following error:
>>
>> OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
>> debug2: ssh_connect: needpriv 0
>> debug1: Connecting to cvs.helixcommunity.org [207.188.25.137] port 22.
>> debug1: connect to address 207.188.25.137 port 22: Connection timed out
>> ssh: connect to host cvs.helixcommunity.org port 22: Connection timed 
>> out
>
> What ssh command line did you use?
>
> I can collect to the same server, so it is not down.
>
> What happened when you type in the following command?
> ssh -v -l yourid cvs.helixcommunity.org
>
> If "ssh -l yourid cvs.helixcommunity.org" doesn't complete without 
> entering your password manually, you might have not completed setting 
> up your CVS access. If you are sure that you have done the steps, then 
> the Helix Community admin should look into the problem.
>
>
>> That's why I downloaded the source from your nightly build.
>>
>> Another question: I'm trying to get the hello_world sample. Since I 
>> cannot connect to the cvs server, I tried to download from the cvs 
>> tree on your web, but I saw HTTP 500 error. Do you know if there is 
>> another way I can get the hello_world sample?
>
> Where did you get the information about the "hello_world" sample?
>
> You can access individual CVS repository from individual project 
> sites; for example, from the player (the GUI on top of Helix Client) 
> project page, and the Helix Client page:
>
> https://player.helixcommunity.org/
> https://helix-client.helixcommunity.org/
>
> you can find the CVS links toward the bottom of the right hand column 
> to the repositories:
> https://helixcommunity.org/plugins/scmcvs/cvsweb.php/?cvsroot=player
> https://helixcommunity.org/plugins/scmcvs/cvsweb.php/?cvsroot=helix-client 
>
>
>
>

-- 
------------------------------------------------------------------------
*Kinson Liu* | Software Development Engineer | RealNetworks, Inc. | 
kliu@real.com | 206.892.6177
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/player-dev/attachments/20061011/4e491bfc/attachment-0001.html
From dyek at real.com  Thu Oct 12 12:58:34 2006
From: dyek at real.com (Daniel Yek)
Date: Thu Oct 12 14:09:40 2006
Subject: [Player-dev] error when building realplayer source
In-Reply-To: <20061012193240.69927.qmail@web34303.mail.mud.yahoo.com>
References: <20061012193240.69927.qmail@web34303.mail.mud.yahoo.com>
Message-ID: <6.2.1.2.2.20061012125118.3251fdb8@mailone.real.com>

Hi Cecilia,

I can connect from home to the cvs server, so, I'm not sure what kind of 
problem is that.

The admin is already looking into the problem. I'm sure they would let you 
know when the problem is resolved.


-- 
Daniel Yek


At 12:32 PM 10/12/2006, you wrote:
>Hi Daniel,
>
>Here is the message I got when I type "ssh -v -l yourid 
>cvs.helixcommunity.org"
>
>$ ssh -v -l cecilialiu cvs.helixcommunity.org
>OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
>debug1: Connecting to cvs.helixcommunity.org [207.188.25.137] port 22.
>debug1: connect to address 207.188.25.137 port 22: Connection timed out
>ssh: connect to host cvs.helixcommunity.org port 22: Connection timed out
>
>I did generated the public key and put it into my helix account from your 
>web. How can I contact Helix
>Community admin about this issue?
>
>Thanks,
>-Cecilia

At 04:05 PM 10/11/2006, Kinson Liu wrote:
>Daniel,
>
>I am afraid it's firewall problem. We are currently working on a 
>get-around on this. Thanks for replying.
>
>Kinson


>----- Original Message ----
>From: Daniel Yek 
>To: sunny day 
>Cc: player-dev@helixcommunity.org
>Sent: Wednesday, October 11, 2006 4:00:56 PM
>Subject: Re: [Player-dev] error when building realplayer source
>
>At 03:31 PM 10/11/2006, sunny day wrote:
> >Thanks Daniel,
> >
> >I wanted to check the source out from your cvs server. I followed the
> >step-by-step instruction on the web, and generated the rsa pub key and put
> >it into my account days ago. I still cannot connect to the cvs server, I
> >got the following error:
> >
> >OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
> >debug2: ssh_connect: needpriv 0
> >debug1: Connecting to cvs.helixcommunity.org [207.188.25.137] port 22.
> >debug1: connect to address 207.188.25.137 port 22: Connection timed out
> >ssh: connect to host cvs.helixcommunity.org port 22: Connection timed out
>
>What ssh command line did you use?
>
>I can collect to the same server, so it is not down.
>
>What happened when you type in the following command?
>ssh -v -l yourid cvs.helixcommunity.org
>
>If "ssh -l yourid cvs.helixcommunity.org" doesn't complete without entering
>your password manually, you might have not completed setting up your CVS
>access. If you are sure that you have done the steps, then the Helix
>Community admin should look into the problem.
>
>
> >That's why I downloaded the source from your nightly build.
> >
> >Another question: I'm trying to get the hello_world sample. Since I cannot
> >connect to the cvs server, I tried to download from the cvs tree on your
> >web, but I saw HTTP 500 error. Do you know if there is another way I can
> >get the hello_world sample?
>
>Where did you get the information about the "hello_world" sample?
>
>You can access individual CVS repository from individual project sites; for
>example, from the player (the GUI on top of Helix Client) project page, and
>the Helix Client page:
>
>https://player.helixcommunity.org/
>https://helix-client.helixcommunity.org/
>
>you can find the CVS links toward the bottom of the right hand column to
>the repositories:
>https://helixcommunity.org/plugins/scmcvs/cvsweb.php/?cvsroot=player
>https://helixcommunity.org/plugins/scmcvs/cvsweb.php/?cvsroot=helix-client
>
>
>
>--
>Daniel Yek
>
>
> >Thanks much,
> >
> >-Cecilia
> >----- Original Message ----
> >From: Daniel Yek 
> >To: sunny day ; player-dev@helixcommunity.org
> >Sent: Wednesday, October 11, 2006 3:25:56 PM
> >Subject: Re: [Player-dev] error when building realplayer source
> >
> >Hi Cecilia,
> >
> >I would rather you use Ribosome to check out source code from CVS and build
> >it from there. There are distribution binaries that will only be available
> >to you after you signed the Binary EULA (BEULA); that is needed to build
> >RealPlayer, but not needed for the Open Source Helix Player.
> >
> >Quick Starts:
> >< mon.helixcommunity.org/2004/devdocs/quickstart>https://common.helixcommunity.org/2004/devdocs/quickstart>https://common.helixcommunity.org/2004/devdocs/quickstart
> >https://player.helixcommunity.org/2005/dev/quickstart.html
> >
> >What is the problem when you build from CVS?
> >
> >Could you follow the Quick Start closely and not deviate from it before you
> >have your first success in building the player? That would help a lot. Some
> >CVS/SSH access problem would resolve in a day or less. So, it would help to
> >keep trying a bit.
> >
> >Thanks.
> >
> >
> >--
> >Daniel Yek
> >
> >
> >At 03:08 PM 10/11/2006, sunny day wrote:
> > >Hi all,
> > >
> > >I downloaded the source code of realplayer. I got the following error
> > >message when I try to do the build by using the Makefile or the make.bat
> > file:
> > >
> > >
> > >getting files
> > >[#-00000160][2006-10-11 12:01:06][172][INFO ] : Checking out source code
> > >and binary distributions.
> > >Group size: 1  Modules: 0  Threads: 2
> > >[#-00000166][2006-10-11 12:01:06][172][INFO ] : Enabling threading, 2
> > >threads requested.
> > >[#-00000168][2006-10-11 12:01:06][172][INFO ] : Starting thread scheduler
> > >to process jobs.
> > >[#-00000172][2006-10-11 12:01:06][172][INFO ] : Thread scheduler run
> > >completed.
> > >
> > >Checkout done in 00:12
> > >compiling
> > >registrating...
> > >modulating...
> > >[#-00000178][2006-10-11 12:01:19][172][INFO ] : Prioritizing module list.
> > >Umake warning: Module does not exist in BIF file.
> > >signing output binaries
> > >Build Complete: Wed Oct 11 12:01:21 2006
> > >copy path="debug" not found
> > >/HelixSDK/build\lib\buildapp.py:1307: DeprecationWarning: raising a string
> > >exception is deprecated
> > >   raise err.error, e
> > >[#-00000224][2006-10-11 12:01:21][172][ERROR] : --- Build System Error
> > >------------------------------------
> > >You have found a Ribosome bug.
> > >-----------------------------------------------------------
> > >--- Python Traceback --------------------------------------
> > >------------------------------------
> > >Traceback (most recent call last):
> > >   File "C:\HelixSDK\build\bin\launcher.py", line 117, in __runTool
> > >     tool.run()
> > >   File "/HelixSDK/build\lib\build_exe.py", line 893, in run
> > >     command_line_args()
> > >   File "/HelixSDK/build\lib\build_exe.py", line 156, in command_line_args
> > >     invoke_buildsystem(arg_list)
> > >   File "/HelixSDK/build\lib\build_exe.py", line 111, in 
> invoke_buildsystem
> > >     app = buildapp.RunBuild(arg_list)
> > >   File "/HelixSDK/build\lib\buildapp.py", line 102, in RunBuild
> > >     app.main()
> > >   File "/HelixSDK/build\lib\buildapp.py", line 196, in main
> > >     self.run()
> > >   File "/HelixSDK/build\lib\buildapp.py", line 400, in run
> > >     self.sign()
> > >   File "/HelixSDK/build\lib\buildapp.py", line 1307, in sign
> > >     raise err.error, e
> > >Build System Error: Cannot list directory="debug".
> > >-----------------------------------------------------------
> > >
> > >C:\HelixSDK\build\bin\launcher.py:131: DeprecationWarning: raising a
> > >string exception is deprecated
> > >   raise
> > >Traceback (most recent call last):
> > >   File "build/bin/build.py", line 67, in 
> > >     tool.run()
> > >   File "C:\HelixSDK\build\bin\launcher.py", line 97, in run
> > >     self.__runTool()
> > >   File "C:\HelixSDK\build\bin\launcher.py", line 117, in __runTool
> > >     tool.run()
> > >   File "/HelixSDK/build\lib\build_exe.py", line 893, in run
> > >     command_line_args()
> > >   File "/HelixSDK/build\lib\build_exe.py", line 156, in command_line_args
> > >     invoke_buildsystem(arg_list)
> > >   File "/HelixSDK/build\lib\build_exe.py", line 111, in 
> invoke_buildsystem
> > >     app = buildapp.RunBuild(arg_list)
> > >   File "/HelixSDK/build\lib\buildapp.py", line 102, in RunBuild
> > >     app.main()
> > >   File "/HelixSDK/build\lib\buildapp.py", line 196, in main
> > >     self.run()
> > >   File "/HelixSDK/build\lib\buildapp.py", line 400, in run
> > >     self.sign()
> > >   File "/HelixSDK/build\lib\buildapp.py", line 1307, in sign
> > >     raise err.error, e
> > >Build System Error: Cannot list directory="debug".
> > >make: *** [all] Error 1
> > >
> > >
> > >Thanks for your attention,
> > >
> > >-Cecilia
> >
> >
>
>


From bidh at midea.com.cn  Thu Oct 12 18:38:19 2006
From: bidh at midea.com.cn (BIDH)
Date: Thu Oct 12 19:51:45 2006
Subject: [Player-dev] Re: a compile error
References: <002601c6e91d$7fbe0200$ed3c16ac@bidh> <45269A59.1080709@real.com>
Message-ID: <005001c6ee68$42fdb310$ed3c16ac@bidh>


RGVhciBHcmVnLA0KICAgIEkgaGF2ZSBmb3VuZCBvdXQgaG93IHRoaXMgZXJyb3Igb2NjdXIuIEFm
dGVyIEkgcmVtb3ZlZCBzb21lIGZ1bmN0aW9uIGRlZmluaXRpb24gaW4gLi9jb21tb24vaW5jbHVk
ZS9hdG9taWNiYXNlLmggLCB0aGUgZXJyb3Igd2FzIGRpc2FwcGVhcmQuDQogICAgTm93IEkgZm91
bmQgYW5vdGhlciBlcnJvcjoNCkVSUk9SOiBTb3VyY2Ugb2JqZWN0IGFybXY0bC1kYmcvc2lwcl9s
aWJzLmEoc2lwcm9maXguc3luZmx0MzIubykgaGFzIEVBQkkgdmVyc2lvbiAwLCBidXQgdGFyZ2V0
IGFybXY0bC1kYmcvc2lwci5zbyBoYXMgRUFCSSB2ZXJpb24gNC4NCg0KICAgIEkgc2VudCBhIG1h
aWwgdG8gdGhlIG1haWxsaXN0IG9mIGFybS1ub25lLWxpbnV4LWdudWVhYmktKiB0b29sY2hhaW4u
DQo+RnJvbTogRGFpaHVpIEJpDQo+VG86IGFybS1nbnVAY29kZXNvdXJjZXJ5LmNvbSA8YXJtLWdu
dUBjb2Rlc291cmNlcnkuY29tPg0KPnN1YmplY3Q6ICAgYWJvdXQgIkVBQkkgdmVyc29uIiBlcnJv
cg0KPg0KPkRlYXIgYWxsLA0KPiAgICBJIGFtIGEgbmV3YmllIG9mIFNvdXJjZXJ5IEcrKyB0b29s
Y2hhaW5zLkkgbWV0IGEgZXJyb3Igc2ltaWxhciB3aXRoIHRoaXMgOg0KPmh0dHA6Ly93d3cuY29k
ZXNvdXJjZXJ5LmNvbS9hcmNoaXZlcy9hcm0tZ251L21zZzAwODg4Lmh0bWwgDQo+DQo+TXkgbWFj
aGluZSBzYXlzIGxpa2UgdGhhdDogIlNvdXJjZSBvYmplY3QgWFhYIGhhcyBFQUJJIHZlcnNpb24g
MCwgYnV0DQo+IHRhcmdldCBZWVkgaGFzIEVBQkkgdmVyc2lvbiA0Ii5NeSBwbGF0Zm9ybSBpcyBB
Uk0xMTM2SkYtUyB0b28uDQo+DQo+ICAgIEkgYWxzbyBmaW5kIHRoYXQgcGFnZToNCj4gaHR0cDov
L3d3dy5jb2Rlc291cmNlcnkuY29tL2FyY2hpdmVzL2FybS1nbnUvbXNnMDA4MDEuaHRtbA0KPlRo
ZSBlcnJvciBtZXNzYWdlIGluIHRoaXMgcGFnZSBpczogIlNvdXJjZSBvYmplY3QgWFhYIGhhcyBF
QUJJIHZlcnNpb24gNCwgYnV0DQo+IHRhcmdldCBZWVkgaGFzIEVBQkkgdmVyc2lvbiAwIi4NCj4N
Cj4gICAgSSBvbmNlIGNoYW5nZWQgbXkgdG9vbGNoYWluIHRvIHZlcnNvbiAyMDA1UTFCLiBUaGUg
ZXJyb3Igd2FzIHN0aWxsIHRoZXJlLg0KPkJlY2F1c2Ugb2YgdGhlIGJlbG93IHdvcmRzLCBJIGRv
bid0IGtub3cgaG93IHRvIHNvbHZlIHRoaXMgRUFCSSBwcm9ibGVtLi4uIA0KPj4+ICAgIEkgd2Fu
dCB0byBrbm93Og0KPj4+IA0KPj4+ICAgMSlJcyB0aGUgY2hhbmdlIGZyb20gLW1hYmk9YXBjcy1n
bnUgdG8gLW1hYmk9YWFwY3MgcmVhbGx5IGZpeCB0aGUgRUFCSQ0KPj4+ICAgIHByb2JsZW0/DQo+
Pj4gICAgMilXb3VsZCB5b3UgcGxlYXNlIHRlbGwgbWUgaG93IHRvIGJ1aWxkIHRoZSBzcmMgcGFj
a2FnZSB0byBlbmFibGUNCj4+PiAgICAiLS1kaXNhYmxlLWxpYnVud2luZC1leGNlcHRpb25zIj8N
Cj4+DQo+Pk5vLiBUaGVyZSBhcmUgc29tZSBvYmplY3RzLCBsaWtlIGxpYmdjYy5hLCB3aGljaCBo
YXZlIGJlZW4gY29tcGlsZWQgdG8NCj4+YmUgRUFCSSBjb21wbGlhbnQuIFRoZXkgY2Fubm90IGJl
IG1peGVkIHdpdGggYW4gLW1hYmk9YWFwY3MgY29tcGlsYXRpb24uDQo+DQo+Q291bGQgYW55Ym9k
eSBoZWxwIG1lPw0KPg0KPkJlc3QgUmVnYXJkcywNCj5EYWlodWkNCg0KICAgIFRoZSBhbnN3ZXIg
aXMgYmVsb3c6DQo+RnJvbTogTWFyayBNaXRjaGVsbCA8bWFya0Bjb2Rlc291cmNlcnkuY29tPg0K
PlRvOiBCSURIIDxiaWRoQG1pZGVhLmNvbS5jbj4NCj5TdWJqZWN0OiBSZTogW2FybS1nbnVdIGFi
b3V0ICJFQUJJIHZlcnNvbiIgZXJyb3INCj5CSURIIHdyb3RlOg0KPj4gRGVhciBhbGwsDQo+PiAg
ICAgSSBhbSBhIG5ld2JpZSBvZiBTb3VyY2VyeSBHKysgdG9vbGNoYWlucy5JIG1ldCBhIGVycm9y
IHNpbWlsYXIgd2l0aCANCj4+IHRoaXMgOg0KPj4gaHR0cDovL3d3dy5jb2Rlc291cmNlcnkuY29t
L2FyY2hpdmVzL2FybS1nbnUvbXNnMDA4ODguaHRtbCANCj4+ICANCj4+IE15IG1hY2hpbmUgc2F5
cyBsaWtlIHRoYXQ6ICIqU291cmNlKiBvYmplY3QgWFhYIGhhcyBFQUJJIHZlcnNpb24gKjAqLCBi
dXQNCj4+ICp0YXJnZXQqIFlZWSBoYXMgRUFCSSB2ZXJzaW9uICo0KiIuTXkgcGxhdGZvcm0gaXMg
QVJNMTEzNkpGLVMgdG9vLg0KPg0KPlRoYXQgbWVhbnMgdGhhdCB5b3UgYXJlIHRyeWluZyB0byBt
aXggRUFCSSBhbmQgbm9uLUVBQkkgb2JqZWN0IGZpbGVzIGluDQo+YSBzaW5nbGUgYXBwbGljYXRp
b24sIHdoaWNoIGRvZXMgbm90IHdvcmsuICBZb3Ugd2lsbCBuZWVkIHRvIHJlY29tcGlsZQ0KPmFs
bCBvZiB0aGUgZmlsZXMgdXNpbmcgdGhlIHNhbWUgQUJJLg0KICAgIEkgZm91bmQgdGhhdCBJIGhh
dmUgc29tZSBub24tRUFCSSBvYmplY3QgZmlsZXMgZnJvbSBjdnMuaGVsaXhjb21tdW5pdHkub3Jn
KHN1Y2ggYXMgc2lwcm9maXguYSkuIEhvdyBjb3VsZCBJIGZpeCB0aGlzIHByb2JsZW0/DQoNCkJl
c3QgUmVnYXJkcywNCkRhaWh1aSBCaQ0KLS0gDQpNYXJrIE1pdGNoZWxsDQpDb2RlU291cmNlcnkN
Cm1hcmtAY29kZXNvdXJjZXJ5LmNvbQ0KKDY1MCkgMzMxLTMzODUgeDcxMw0KDQoNCi0tLS0tIE9y
aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiR3JlZyBXcmlnaHQiIDxnd3JpZ2h0QHJlYWwu
Y29tPg0KVG86ICJCSURIIiA8YmlkaEBtaWRlYS5jb20uY24+DQpDYzogPHBsYXllci1kZXZAaGVs
aXhjb21tdW5pdHkub3JnPg0KU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMDcsIDIwMDYgMjowMyBB
TQ0KU3ViamVjdDogUmU6IGEgY29tcGlsZSBlcnJvcg0KDQoNCj4gDQo+IEJJREggd3JvdGU6DQo+
PiBEZWFyIEdyZWcsDQo+PiAgICAgICAgIFdoZW4gSSBjaGFuZ2UgbXkgdG9vbGNoYWluIGZyb20g
YXJtLWxpbnV4LSB0byBhcm0tbm9uZS1saW51eC1nbnVlYWJpLSAsSSBtZXQgYW4gZXJyb3IgbGlr
ZSBiZWxvdzoNCj4+IEVudGVyaW5nIGRpcmVjdG9yeSAnL3Vzci9oZWxpeC9jb21tb24vc3lzdGVt
Jw0KPj4gYXJtLW5vbmUtbGludXgtZ251ZWFiaS1nKysgLXBpcGUgLVcgLVdyZXR1cm4tdHlwZSAt
Zm5vLWV4Y2VwdGlvbnMgLW1hcmNoPWFybXY0dCAtLXBlcm1pc3NpdmUgLWZuby1ydHRpIC1PMCAt
bWFiaS1hYXBjcy1saW51eCAtbWZwdT12ZnAgLW1mbG9hdC1hYmk9c29mdGZwIC1nIC1EREVCVUcg
LURfREVCVUcgLUkuLi8uLi9jb21tb24vcnVudGltZS9wdWIgLUlwdWIvcGxhdGZvcm0vdW5peCAt
SS4uL2luY2x1ZGUgLUkuLi9jb250YWluZXIvcHViIC1JLi4vZGJndG9vbC9wdWIgLUkuLi91dGls
L3B1YiAtSS4uL2ZpbGVpby9wdWIgLUkuLi9ydW50aW1lL3B1YiAtSS4vcHViIC1JLiAtaW5jbHVk
ZSBhcm12NGwtZGViZy9jb21tb25fc3lzdGVtX3JpYm9kZWZzLmggLWZQSUMgLURQSUMgLW8gYXJt
djRsLWRiZy9vYmovZGxscGF0aC5vIC1jIGRsbHBhdGguY3BwDQo+PiB7c3RhbmRhcmQgaW5wdXR9
OiBBc3NlbWJsZXIgbWVzc2FnZXM6DQo+PiB7c3RhbmRhcmQgaW5wdXR9OjM2OiBFcnJvcjogbWlz
YWxpZ25lZCBicmFuY2ggZGVzdGluYXRpb24NCj4+IHtzdGFuZGFyZCBpbnB1dH06Nzg6IEVycm9y
OiBtaXNhbGlnbmVkIGJyYW5jaCBkZXN0aW5hdGlvbg0KPj4gDQo+PiBDb3VsZCB5b3UgZ2l2ZSBt
ZSBhbnkgc3VnZ2VzdGlvbiB0byBzb2x2ZSB0aGlzIHByb2JsZW0/DQo+IA0KPiBJIHJlYWxseSBo
YXZlIG5vIGlkZWEuIEkgaGF2ZSBub3QgdXNlZCAiYXJtLW5vbmUtbGludXgtZ251ZWFiaS0qIiBi
ZWZvcmUuDQo+IA0KPiBCdXQsIGl0IGxvb2tzIGxpa2UgeW91IG5lZWQgdG8gdHdlYWsgeW91ciBj
b21waWxlciBmbGFncyBwZXJoYXBzLg0KPiBFaXRoZXIgd2F5LCBnKysgaXMgb3V0cHV0aW5nIGJh
ZCBBU00gb3IgQVNNIHRoYXQgaXMgbm90IGNvcnJlY3QNCj4gZm9yIHlvdXIgcGxhdGZvcm0uDQo+
IA0KPiAtLWdyZWcuDQo+IA0KPj4gDQo+PiBCZXN0IFJlZ2FyZHMsDQo+PiBEYWlodWkgQmkNCj4+
IA0KPj4gICAgICAgICANCj4=



From dyek at real.com  Fri Oct 13 15:13:40 2006
From: dyek at real.com (Daniel Yek)
Date: Fri Oct 13 16:28:13 2006
Subject: [Player-dev] error when building realplayer source on Windows
In-Reply-To: <20061013220416.1583.qmail@web34309.mail.mud.yahoo.com>
References: <20061013220416.1583.qmail@web34309.mail.mud.yahoo.com>
Message-ID: <6.2.1.2.2.20061013150643.4362d778@mailone.real.com>

Hi Cecilia,

Do you have log.py in C:\HelixSDK\build\lib\ directory?

Anyway, the (Real) Player project is for Linux only. The released 
RealPlayer for Windows isn't built from this player project.

You can build Helix Client, in the form of a command line utility called 
splay on Windows though.

Thanks.

-- 

Daniel Yek


At 03:04 PM 10/13/2006, sunny day wrote:
>Hi Daniel,
>
>Can I ask you a stupid question? When I was trying  "python build.py" I 
>got the following error, what's wrong?
>
>python build.py
>Traceback (most recent call last):
>   File "build.py", line 65, in 
>     import launcher
>   File "C:\HelixSDK\build\bin\launcher.py", line 77, in 
>     import log
>ImportError: No module named log
>
>Another question: how to build the hello_world sample?
>
>Thanks for your attention,
>
>-Cecilia


From dyek at real.com  Mon Oct 16 11:45:28 2006
From: dyek at real.com (Daniel Yek)
Date: Mon Oct 16 12:59:24 2006
Subject: [Player-dev] Re: error when building realplayer source on Windows
In-Reply-To: <20061016182557.16361.qmail@web34309.mail.mud.yahoo.com>
References: <20061016182557.16361.qmail@web34309.mail.mud.yahoo.com>
Message-ID: <6.2.1.2.2.20061016113107.6b976b00@mailone.real.com>

Hi Cecilia,

[BCC player-dev, CC helix-client-dev.]

Please keep the email list so that others who know more can reply to it.

At 11:25 AM 10/16/2006, sunny day wrote:
>Hi Daniel,
>
>Yes, I do have log.py in C:\HelixSDK\build\lib.
>
> >Anyway, the (Real) Player project is for Linux only. The released
>RealPlayer for Windows isn't built from this player project.
>
>Now, I'm confused now. Does it mean (Real) Player does not support windows 
>plugin? If RealPlayer does support windows plugin, where can I get the SDK 
>and find some plugin examples? I only need to do windows plugin for now.

What I meant was that player-dev@helixcommunity.org and 
player.helixcommunity.org are mostly for Helix and RealPlayer for Linux.

I'm forwarding your email to helix-client-dev. There are more experts 
familiar with creating RealPlayer plugin for Windows.

You can take a look at RealPlayer For Windows Customer Service web site, if 
it is applicable to you:
http://service.real.com/contact/help.html?product=rp

Thanks.


-- 
Daniel Yek


>Regards,
>
>-Cecilia
>
>----- Original Message ----
>From: Daniel Yek 
>To: sunny day 
>Cc: Player-dev 
>Sent: Friday, October 13, 2006 3:13:40 PM
>Subject: error when building realplayer source on Windows
>
>Hi Cecilia,
>
>Do you have log.py in C:\HelixSDK\build\lib\ directory?
>
>Anyway, the (Real) Player project is for Linux only. The released
>RealPlayer for Windows isn't built from this player project.
>
>You can build Helix Client, in the form of a command line utility called
>splay on Windows though.
>
>Thanks.
>
>--
>
>Daniel Yek
>
>
>At 03:04 PM 10/13/2006, sunny day wrote:
> >Hi Daniel,
> >
> >Can I ask you a stupid question? When I was trying  "python build.py" I
> >got the following error, what's wrong?
> >
> >python build.py
> >Traceback (most recent call last):
> >   File "build.py", line 65, in 
> >     import launcher
> >   File "C:\HelixSDK\build\bin\launcher.py", line 77, in 
> >     import log
> >ImportError: No module named log
> >
> >Another question: how to build the hello_world sample?
> >
> >Thanks for your attention,
> >
> >-Cecilia
>
>


From dyek at real.com  Mon Oct 16 13:19:18 2006
From: dyek at real.com (Daniel Yek)
Date: Mon Oct 16 14:33:10 2006
Subject: [Player-dev] CR-Client: ICT (Internet Connection Test) improvement
	work
Message-ID: <6.2.1.2.2.20061016131600.6a724ff0@mailone.real.com>

Modified by: dyek@real.com
Date: 10/16/2006
Project: Helix Player

Synopsis: This check-in adds and polishes numerous ICT functionalities and 
fixes bugs.

Overview:
Introduced a pipe connecting the POSIX/UNIX signal handler to GTK+
I/O Channel so that the POSIX signal handler can avoid unsafe function
calls. This solved the "instability" bug experienced when there is no
Internet connection.

Implemented functionality to select the fastest from multiple perftest
sites. Currently, there are 2 perftest sites, one USA-based, the other
UK-based.

Now, the implementation can handle the case where slow download is still
going on when it timed out. In USA, this duration could have been 1 second,
even for 14.4 kbps modem connection, and an accurate bandwidth measurement
could still be obtained. However, this implementation handles TCP connection
timeout by capping it to 3 seconds per download and implement perftest
site-selection, so we can't actually set the duration of ICT
(Internet Connection Test) to 1 sec.
The duration is currently set to 10 seconds so that the test can work
better for more oversea users.

The implementation has been subjected to a lot of simulated tests during
development and it was working well.
Error handling is much improved. TCP/IP stack (or/and name resolver) is
warmed up before bandwidth tests are started;
that improved selection of perftest site significantly.


Files Modified:
player/app/gtk/ict_wget.c - Contains the bulk of the work.
player/app/gtk/ict.cpp -  added "Undefined" bandwidth text; handle timeout
   callback better.

player/app/gtk/ict.h      - Remove an unused function parameter.
player/app/gtk/ict_wget.h - Added some function prototypes.
player/app/gtk/ict_interface.c - Changes in label text.
player/app/gtk/res/ict.glade - Changed label text.

player/app/gtk/setup.cpp - Connect window delete_event callback.
player/app/gtk/prefsdialog.cpp - Minor change in callback function prototype.


Image Size and Heap Use impact (Client -Only):
None.

Platforms and Profiles Affected:
Linux

Distribution Libraries Affected:
None.

Distribution library impact and planned action:
None.

Platforms and Profiles Build Verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Platforms and Profiles Functionality verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Branch: HEAD

Copyright assignment: I am a RealNetworks employee.





-- 
Daniel Yek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ict_err_handl[1].tgz
Type: application/octet-stream
Size: 39972 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/player-dev/attachments/20061016/c2ca1bb2/ict_err_handl1-0001.obj
From bobclark at real.com  Mon Oct 16 19:09:55 2006
From: bobclark at real.com (Bob Clark)
Date: Mon Oct 16 20:21:40 2006
Subject: [Player-dev] CR-Client: ICT (Internet Connection Test)
	improvement work
In-Reply-To: <6.2.1.2.2.20061016131600.6a724ff0@mailone.real.com>
References: <6.2.1.2.2.20061016131600.6a724ff0@mailone.real.com>
Message-ID: <6.2.1.2.2.20061016190936.039aafc0@mailone.real.com>

Looks good, Daniel.
--Bob

At 01:19 PM 10/16/2006, Daniel Yek wrote:
>Modified by: dyek@real.com
>Date: 10/16/2006
>Project: Helix Player
>
>Synopsis: This check-in adds and polishes numerous ICT functionalities and 
>fixes bugs.
>
>Overview:
>Introduced a pipe connecting the POSIX/UNIX signal handler to GTK+
>I/O Channel so that the POSIX signal handler can avoid unsafe function
>calls. This solved the "instability" bug experienced when there is no
>Internet connection.
>
>Implemented functionality to select the fastest from multiple perftest
>sites. Currently, there are 2 perftest sites, one USA-based, the other
>UK-based.
>
>Now, the implementation can handle the case where slow download is still
>going on when it timed out. In USA, this duration could have been 1 second,
>even for 14.4 kbps modem connection, and an accurate bandwidth measurement
>could still be obtained. However, this implementation handles TCP connection
>timeout by capping it to 3 seconds per download and implement perftest
>site-selection, so we can't actually set the duration of ICT
>(Internet Connection Test) to 1 sec.
>The duration is currently set to 10 seconds so that the test can work
>better for more oversea users.
>
>The implementation has been subjected to a lot of simulated tests during
>development and it was working well.
>Error handling is much improved. TCP/IP stack (or/and name resolver) is
>warmed up before bandwidth tests are started;
>that improved selection of perftest site significantly.
>
>
>Files Modified:
>player/app/gtk/ict_wget.c - Contains the bulk of the work.
>player/app/gtk/ict.cpp -  added "Undefined" bandwidth text; handle timeout
>   callback better.
>
>player/app/gtk/ict.h      - Remove an unused function parameter.
>player/app/gtk/ict_wget.h - Added some function prototypes.
>player/app/gtk/ict_interface.c - Changes in label text.
>player/app/gtk/res/ict.glade - Changed label text.
>
>player/app/gtk/setup.cpp - Connect window delete_event callback.
>player/app/gtk/prefsdialog.cpp - Minor change in callback function prototype.
>
>
>Image Size and Heap Use impact (Client -Only):
>None.
>
>Platforms and Profiles Affected:
>Linux
>
>Distribution Libraries Affected:
>None.
>
>Distribution library impact and planned action:
>None.
>
>Platforms and Profiles Build Verified:
>Profile: helix_client_all_define
>Platform: Fedora Core 5
>
>Platforms and Profiles Functionality verified:
>Profile: helix_client_all_define
>Platform: Fedora Core 5
>
>Branch: HEAD
>
>Copyright assignment: I am a RealNetworks employee.
>
>
>
>
>
>--
>Daniel Yek
>
>
>
>_______________________________________________
>Player-dev mailing list
>Player-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/player-dev



From dyek at real.com  Mon Oct 16 19:46:51 2006
From: dyek at real.com (Daniel Yek)
Date: Mon Oct 16 21:00:38 2006
Subject: [Player-dev] CN-Client: ICT (Internet Connection Test) improvement
	work
In-Reply-To: <6.2.1.2.2.20061016190936.039aafc0@mailone.real.com>
References: <6.2.1.2.2.20061016131600.6a724ff0@mailone.real.com>
	<6.2.1.2.2.20061016190936.039aafc0@mailone.real.com>
Message-ID: <6.2.1.2.2.20061016194543.1cbba650@mailone.real.com>

Thank you, Bob. This is now checked into HEAD.


-- 
Daniel Yek

At 07:09 PM 10/16/2006, Bob Clark wrote:
>Looks good, Daniel.
>--Bob
>
>At 01:19 PM 10/16/2006, Daniel Yek wrote:
>>Modified by: dyek@real.com
>>Date: 10/16/2006
>>Project: Helix Player
>>
>>Synopsis: This check-in adds and polishes numerous ICT functionalities 
>>and fixes bugs.
>>
>>Overview:
>>Introduced a pipe connecting the POSIX/UNIX signal handler to GTK+
>>I/O Channel so that the POSIX signal handler can avoid unsafe function
>>calls. This solved the "instability" bug experienced when there is no
>>Internet connection.
>>
>>Implemented functionality to select the fastest from multiple perftest
>>sites. Currently, there are 2 perftest sites, one USA-based, the other
>>UK-based.
>>
>>Now, the implementation can handle the case where slow download is still
>>going on when it timed out. In USA, this duration could have been 1 second,
>>even for 14.4 kbps modem connection, and an accurate bandwidth measurement
>>could still be obtained. However, this implementation handles TCP connection
>>timeout by capping it to 3 seconds per download and implement perftest
>>site-selection, so we can't actually set the duration of ICT
>>(Internet Connection Test) to 1 sec.
>>The duration is currently set to 10 seconds so that the test can work
>>better for more oversea users.
>>
>>The implementation has been subjected to a lot of simulated tests during
>>development and it was working well.
>>Error handling is much improved. TCP/IP stack (or/and name resolver) is
>>warmed up before bandwidth tests are started;
>>that improved selection of perftest site significantly.
>>
>>
>>Files Modified:
>>player/app/gtk/ict_wget.c - Contains the bulk of the work.
>>player/app/gtk/ict.cpp -  added "Undefined" bandwidth text; handle timeout
>>   callback better.
>>
>>player/app/gtk/ict.h      - Remove an unused function parameter.
>>player/app/gtk/ict_wget.h - Added some function prototypes.
>>player/app/gtk/ict_interface.c - Changes in label text.
>>player/app/gtk/res/ict.glade - Changed label text.
>>
>>player/app/gtk/setup.cpp - Connect window delete_event callback.
>>player/app/gtk/prefsdialog.cpp - Minor change in callback function prototype.
>>
>>
>>Image Size and Heap Use impact (Client -Only):
>>None.
>>
>>Platforms and Profiles Affected:
>>Linux
>>
>>Distribution Libraries Affected:
>>None.
>>
>>Distribution library impact and planned action:
>>None.
>>
>>Platforms and Profiles Build Verified:
>>Profile: helix_client_all_define
>>Platform: Fedora Core 5
>>
>>Platforms and Profiles Functionality verified:
>>Profile: helix_client_all_define
>>Platform: Fedora Core 5
>>
>>Branch: HEAD
>>
>>Copyright assignment: I am a RealNetworks employee.
>>
>>
>>
>>
>>
>>--
>>Daniel Yek


From dyek at real.com  Fri Oct 20 11:56:18 2006
From: dyek at real.com (Daniel Yek)
Date: Fri Oct 20 13:05:44 2006
Subject: [Player-dev] CR-Client: Hook up the ABD checkbox with
 AutoBWDetection Helix preference.
Message-ID: <6.2.1.2.2.20061020115140.044c0fe8@mailone.real.com>

Modified by: dyek@real.com
Date: 10/20/2006
Project: Helix Player

Synopsis: Hook up the ABD checkbox with AutoBWDetection Helix preference.

Overview:
(1)
Hook up the ABD (Auto Bandwidth Detection) checkbox with AutoBWDetection
Helix preference.

(2)
Removed g_signal_connect_swap() and replaced it with a call to
gtk_widget_get_toplevel(), consistent with the rest of the functions.

At the same time, clean up (GObject's) signal handler callback function
prototypes, so that preference_callbacks.h can be used directly.



Files Modified:
player/app/gtk/prefsdialog.cpp - Connected the ABD checkbox with
     AutoBWDetection Helix preference; changed function prototypes to
     match Glade.

player/app/gtk/preferences_interface.c - Replaced g_signal_connect_swap()
     with the non-swap version, so function prototypes generated by Glade-2
     isn't messed up.
player/app/gtk/res/preferences.glade - Replaced g_signal_connect_swap().
player/app/gtk/preferences_callbacks.h - Replaced g_signal_connect_swap().

player/app/gtk/commonapp.h - Include Glade's _callbacks.h header in
     'extern "C"'
player/app/gtk/commonapp.cpp - Change a function prototype to match Glade.


Image Size and Heap Use impact (Client -Only):
None.

Platforms and Profiles Affected:
Linux

Distribution Libraries Affected:
None.

Distribution library impact and planned action:
None.

Platforms and Profiles Build Verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Platforms and Profiles Functionality verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Branch: HEAD

Copyright assignment: I am a RealNetworks employee.



-- 
Daniel Yek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cr_abd_prefs[1].tgz
Type: application/octet-stream
Size: 51917 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/player-dev/attachments/20061020/d315bb1d/cr_abd_prefs1-0001.obj
From bobclark at real.com  Fri Oct 20 12:22:14 2006
From: bobclark at real.com (Bob Clark)
Date: Fri Oct 20 13:49:03 2006
Subject: [Player-dev] CR-Client: Hook up the ABD checkbox with
	AutoBWDetection Helix preference.
In-Reply-To: <6.2.1.2.2.20061020115140.044c0fe8@mailone.real.com>
References: <6.2.1.2.2.20061020115140.044c0fe8@mailone.real.com>
Message-ID: <6.2.1.2.2.20061020121124.038e4160@mailone.real.com>

Looks good, Daniel.

--Bob

At 11:56 AM 10/20/2006, Daniel Yek wrote:
>Modified by: dyek@real.com
>Date: 10/20/2006
>Project: Helix Player
>
>Synopsis: Hook up the ABD checkbox with AutoBWDetection Helix preference.
>
>Overview:
>(1)
>Hook up the ABD (Auto Bandwidth Detection) checkbox with AutoBWDetection
>Helix preference.
>
>(2)
>Removed g_signal_connect_swap() and replaced it with a call to
>gtk_widget_get_toplevel(), consistent with the rest of the functions.
>
>At the same time, clean up (GObject's) signal handler callback function
>prototypes, so that preference_callbacks.h can be used directly.
>
>
>
>Files Modified:
>player/app/gtk/prefsdialog.cpp - Connected the ABD checkbox with
>     AutoBWDetection Helix preference; changed function prototypes to
>     match Glade.
>
>player/app/gtk/preferences_interface.c - Replaced g_signal_connect_swap()
>     with the non-swap version, so function prototypes generated by Glade-2
>     isn't messed up.
>player/app/gtk/res/preferences.glade - Replaced g_signal_connect_swap().
>player/app/gtk/preferences_callbacks.h - Replaced g_signal_connect_swap().
>
>player/app/gtk/commonapp.h - Include Glade's _callbacks.h header in
>     'extern "C"'
>player/app/gtk/commonapp.cpp - Change a function prototype to match Glade.
>
>
>Image Size and Heap Use impact (Client -Only):
>None.
>
>Platforms and Profiles Affected:
>Linux
>
>Distribution Libraries Affected:
>None.
>
>Distribution library impact and planned action:
>None.
>
>Platforms and Profiles Build Verified:
>Profile: helix_client_all_define
>Platform: Fedora Core 5
>
>Platforms and Profiles Functionality verified:
>Profile: helix_client_all_define
>Platform: Fedora Core 5
>
>Branch: HEAD
>
>Copyright assignment: I am a RealNetworks employee.
>
>
>
>--
>Daniel Yek
>
>
>
>_______________________________________________
>Player-dev mailing list
>Player-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/player-dev



From dyek at real.com  Fri Oct 20 12:54:55 2006
From: dyek at real.com (Daniel Yek)
Date: Fri Oct 20 14:04:17 2006
Subject: [Player-dev] CN-Client: Hook up the ABD checkbox with
 AutoBWDetection Helix preference.
In-Reply-To: <6.2.1.2.2.20061020121124.038e4160@mailone.real.com>
References: <6.2.1.2.2.20061020115140.044c0fe8@mailone.real.com>
	<6.2.1.2.2.20061020121124.038e4160@mailone.real.com>
Message-ID: <6.2.1.2.2.20061020125403.048ecd60@mailone.real.com>

This is now checked in.

Thanks Bob.


-- 
Daniel Yek

At 12:22 PM 10/20/2006, Bob Clark wrote:
>Looks good, Daniel.
>
>--Bob
>
>At 11:56 AM 10/20/2006, Daniel Yek wrote:
>>Modified by: dyek@real.com
>>Date: 10/20/2006
>>Project: Helix Player
>>
>>Synopsis: Hook up the ABD checkbox with AutoBWDetection Helix preference.
>>
>>Overview:
>>(1)
>>Hook up the ABD (Auto Bandwidth Detection) checkbox with AutoBWDetection
>>Helix preference.
>>
>>(2)
>>Removed g_signal_connect_swap() and replaced it with a call to
>>gtk_widget_get_toplevel(), consistent with the rest of the functions.
>>
>>At the same time, clean up (GObject's) signal handler callback function
>>prototypes, so that preference_callbacks.h can be used directly.
>>
>>
>>
>>Files Modified:
>>player/app/gtk/prefsdialog.cpp - Connected the ABD checkbox with
>>     AutoBWDetection Helix preference; changed function prototypes to
>>     match Glade.
>>
>>player/app/gtk/preferences_interface.c - Replaced g_signal_connect_swap()
>>     with the non-swap version, so function prototypes generated by Glade-2
>>     isn't messed up.
>>player/app/gtk/res/preferences.glade - Replaced g_signal_connect_swap().
>>player/app/gtk/preferences_callbacks.h - Replaced g_signal_connect_swap().
>>
>>player/app/gtk/commonapp.h - Include Glade's _callbacks.h header in
>>     'extern "C"'
>>player/app/gtk/commonapp.cpp - Change a function prototype to match Glade.
>>
>>
>>Image Size and Heap Use impact (Client -Only):
>>None.
>>
>>Platforms and Profiles Affected:
>>Linux
>>
>>Distribution Libraries Affected:
>>None.
>>
>>Distribution library impact and planned action:
>>None.
>>
>>Platforms and Profiles Build Verified:
>>Profile: helix_client_all_define
>>Platform: Fedora Core 5
>>
>>Platforms and Profiles Functionality verified:
>>Profile: helix_client_all_define
>>Platform: Fedora Core 5
>>
>>Branch: HEAD
>>
>>Copyright assignment: I am a RealNetworks employee.
>>
>>
>>
>>--
>>Daniel Yek


From dyek at real.com  Tue Oct 24 07:14:19 2006
From: dyek at real.com (Daniel Yek)
Date: Tue Oct 24 08:22:51 2006
Subject: [Player-dev] CR-Client: Support multi-channel playback on Linux
	using ALSA 
Message-ID: <6.2.1.2.2.20061024070838.3968e798@mailone.real.com>


Modified by: dyek@real.com
Date: 10/24/2006
Project: Helix Player

Synopsis: Currently, we hear 2 channels only when playing 5.1 channels content
   with Helix and RealPlayer.
   This change enables multi-channels playback on ALSA.

Overview:
(1)
   Many member functions implementation in Helix Client Core's ALSA audio
   device code, audlinux_alsa.cpp, share the same member variable,
   m_wLastError.

   When an error occurred in a member function, the ending _CloseAudio()
   call can wipe out the existing error condition.

   The code looked like this:

   m_wLastError = RA_AOE_BADFORMAT;
   _CloseAudio();  // This function always set: "m_wLastError = RA_AOE_NOERR;"
   return m_wLastError;

   So, we always returned RA_AOE_NOERR in _CheckFormat(), even when the system
   can't play the format.

(2)
   The implementation was catered for 2-channel playback only.
   Playing back 5.1 channels content caused ALSA's "default" PCM device to
   invoke its ("plug" and) "route" plugin and shrink the channels to 2 
channels,
   discarding surround sound content.

   The right ALSA PCM device to use to play 5.1 content is the 
"plug:surround51" PCM,
   which only takes 6-channel input.

   If the system isn't set up to play 5.1 content, snd_pcm_open() this PCM
   would fail and Helix client would then fallback to 2-channel and use the
   "default" PCM.

   Note that on some mis-configured system, "plug:surround51" was defined 
even though
   the system isn't 5.1 capable. This is system configuration problem.
   On such system, ALSA would invoke the "plug" plugin, which uses "route" 
plugin to
   discard surround sound content and playback in 2-channel mode.
   On these systems, we really want to have Helix client "preserve" all 
channels by
   down-mixing it to 2 channels.

(3)
   ALSA now always configures the sound card to 48000Hz.
   So, Helix's ALSA audio device _CheckFormat() code now forces Helix client
   to use 48000Hz.



Files Modified:
audio/device/platform/unix/audlinux_alsa.cpp  - Support surround sound 
playback.
audio/device/platform/unix/audlinux_oss.cpp   - _OpenAudio() prototype changed.
audio/device/platform/unix/audUnix.cpp        - _OpenAudio() prototype changed.
audio/device/pub/platform/unix/audlinux_alsa.h
audio/device/pub/platform/unix/audlinux_oss.h - _OpenAudio() prototype changed.
audio/device/pub/platform/unix/audUnix.h      - _OpenAudio() prototype changed.

player/app/gtk/prefsdialog.cpp          - Added 5.1 ALSA Device preference 
entry.
player/app/gtk/res/preferences.glade    - Added 5.1 ALSA Device Text Entry.
player/app/gtk/preferences_interface.c  - Generated code.

Platforms and Profiles Affected:
Linux

Platforms and Profiles Build Verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Platforms and Profiles Functionality verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Branch: 150Cay and HEAD
(Will work on HEAD branch after 150Cay checkin is done.)

Copyright assignment: I am a RealNetworks employee.


-- 
Daniel Yek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cr[1].tgz
Type: application/octet-stream
Size: 76612 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/player-dev/attachments/20061024/1c1e51bc/cr1-0001.obj
From dyek at real.com  Tue Oct 24 09:37:21 2006
From: dyek at real.com (Daniel Yek)
Date: Tue Oct 24 10:45:50 2006
Subject: [Player-dev] CR-Client: Changing Volume Control to not touch system
 volume; Software Volume Control (#2)
Message-ID: <6.2.1.2.2.20061024093431.3a2f0270@mailone.real.com>


Modified by: dyek@real.com
Date: 10/24/2006
Project: Helix Player

Synopsis: Helix Player was changing the System/PCM/Device Volume and users
   expressed desire for application volume control to not influence system
   volume. This is another fix.

Overview:
   This is the previous CR.
   http://lists.helixcommunity.org/pipermail/player-dev/2006-September/002491.html

   We have changed the approach used to address this problem.
   In this patch, we are sticking to volume control interface returned by:
     3. Audio device volume control = IHXAudioPlayer::GetDeviceVolume()

   GetDeviceVolume() was used in the released players.
   Until now, this volume control has been the:
     system audio device volume control
   which is ALSA's PCM device.

   This patch turns this device Volume Control into:
     Helix audio device volume control
   This one being software volume control.

   This patch utilizes Helix Gaintool to attenuate the volume. (Despite the 
name.)
   Gaintool changes the audio volume smoothly, without introducing abrupt
   changes.

   Also, by implementing the software volume control in Helix's ALSA device
   code, the response delay is capped to about 0.3 second with smooth changes
   extends slightly beyond 0.6 second.
   In other words, this is a much better implementation than I was originally
   set to work on. (The delay is capped and Gaintool is utilized.)

   When the player volume is set to 100, and when Gaintool has came to the
   steady state, audio data is then sent directly to the system audio device by
   passing Gaintool processing.
   That means that the user always get the best audio quality when the volume
   is set to 100, (which corresponds 100% of the system volume,) and then the
   system-provided volume control is used to set the desired volume control,
   because no change of audio data occurs -- Gaintool not processing it.

   Volume saving and restoring is implemented using the "volume" preference.

   This fix only implement software volume control in Helix's ALSA device code,
   not in OSS. When the volume control preference is set to OSS, the volume
   control still changes system volume.


Files Modified:
audio/device/platform/unix/audlinux_alsa.cpp  - Implement Software Volume
     Control and Gaintool interface code.
audio/device/platform/unix/audlinux_alsa.h    - Member variables, macros.

player/hxclientkit/src/CHXClientPlayer.cpp    - "volume" preference.
player/hxclientkit/src/CHXClientPlayer.h      - Member variable for engine 
callback.

audio/device/auddevlib_linux2.pcf - Added gain.h include path.
audio/gaintool/gain.c       - Added gainIsSteadyState().
audio/gaintool/pub/gain.h   - Added gainIsSteadyState().
client/audiosvc/pub/mixengine.h - Move static utility member functions to 
public.


Platforms and Profiles Affected:
Linux

Platforms and Profiles Build Verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Platforms and Profiles Functionality verified:
Profile: helix_client_all_define
Platform: Fedora Core 5

Branch: HEAD

Copyright assignment: I am a RealNetworks employee.




-- 
Daniel Yek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cr[1].tgz
Type: application/octet-stream
Size: 34367 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/player-dev/attachments/20061024/cb6309f4/cr1-0001.obj
From gwright at real.com  Tue Oct 24 11:32:40 2006
From: gwright at real.com (Greg Wright)
Date: Tue Oct 24 12:44:45 2006
Subject: [Player-dev] Re: [Helix-client-dev] CR-Client: Support
 multi-channel playback on	Linux using ALSA
In-Reply-To: <6.2.1.2.2.20061024070838.3968e798@mailone.real.com>
References: <6.2.1.2.2.20061024070838.3968e798@mailone.real.com>
Message-ID: <453E5C48.7030205@real.com>

Daniel Yek wrote:
> 
> Modified by: dyek@real.com
> Date: 10/24/2006
> Project: Helix Player
> 
> Synopsis: Currently, we hear 2 channels only when playing 5.1 channels 
> content
>   with Helix and RealPlayer.
>   This change enables multi-channels playback on ALSA.
> 
> Overview:
> (1)
>   Many member functions implementation in Helix Client Core's ALSA audio
>   device code, audlinux_alsa.cpp, share the same member variable,
>   m_wLastError.
> 
>   When an error occurred in a member function, the ending _CloseAudio()
>   call can wipe out the existing error condition.
> 
>   The code looked like this:
> 
>   m_wLastError = RA_AOE_BADFORMAT;
>   _CloseAudio();  // This function always set: "m_wLastError = 
> RA_AOE_NOERR;"
>   return m_wLastError;
> 
>   So, we always returned RA_AOE_NOERR in _CheckFormat(), even when the 
> system
>   can't play the format.
> 
> (2)
>   The implementation was catered for 2-channel playback only.
>   Playing back 5.1 channels content caused ALSA's "default" PCM device to
>   invoke its ("plug" and) "route" plugin and shrink the channels to 2 
> channels,
>   discarding surround sound content.
> 
>   The right ALSA PCM device to use to play 5.1 content is the 
> "plug:surround51" PCM,
>   which only takes 6-channel input.
> 
>   If the system isn't set up to play 5.1 content, snd_pcm_open() this PCM
>   would fail and Helix client would then fallback to 2-channel and use the
>   "default" PCM.
> 
>   Note that on some mis-configured system, "plug:surround51" was defined 
> even though
>   the system isn't 5.1 capable. This is system configuration problem.
>   On such system, ALSA would invoke the "plug" plugin, which uses 
> "route" plugin to
>   discard surround sound content and playback in 2-channel mode.
>   On these systems, we really want to have Helix client "preserve" all 
> channels by
>   down-mixing it to 2 channels.

So, do we properly handle mis-configured systems? If not, we should. At
least we should have a pref that will let users force 2-channel playback,
if we don't already.

> 
> (3)
>   ALSA now always configures the sound card to 48000Hz.
>   So, Helix's ALSA audio device _CheckFormat() code now forces Helix client
>   to use 48000Hz.

Is this the case for *all* ALSA systems out in the wild? If not, we need
to handle that.


I am only reviewing the core parts below. In the future you should
break up the CR so that at least the core parts are seperate. If
someone sees me respond to this CR they may assume that I
looked at all of it and not read it. They you also don't have to
cross post to many lists (helix-client-dev is never used for CRs,
audio-dev would have been fine for just the core parts).

-    virtual HX_RESULT _OpenAudio() = 0;
+    virtual HX_RESULT _OpenAudio( const HXAudioFormat* pFormat ) = 0;

I am not sure I like changing this in audUnix.h. If you do, you need
to change it everywhere, not just ALSA and OSS:

D:\cygwin\home\gwright\helix\audio\device\pub\platform\openwave\audopwave.h(205):    virtual HX_RESULT _OpenAudio();
D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audhpux.h(100):    virtual HX_RESULT _OpenAudio();
D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audirix.h(100):    virtual HX_RESULT _OpenAudio();
D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audlinux_alsa.h(99):    virtual HX_RESULT _OpenAudio();
D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audlinux_esound.h(118):    virtual HX_RESULT _OpenAudio();
D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audlinux_oss.h(110):    virtual HX_RESULT _OpenAudio();
D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audSolaris.h(102):    virtual HX_RESULT _OpenAudio();
D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audUnix.h(221):    virtual HX_RESULT _OpenAudio() = 0;
D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audusound.h(100):    virtual HX_RESULT _OpenAudio();

I think it would be better, since they all inherit from audUnix, that you
just store the format in a member var (maybe a new one in audUnix) and
let the child classes use it. So, in _OpenAudio they already have the
format in, for example, m_pAudioFormat.



+
+    if (m_bCheckFormat)
+    {
+        // Print ALSA PCM device name while doing checking format.
+        HXLOGL4 (HXLOG_ADEV, "Opening ALSA PCM device, %s, to check format!", szDevice);
+    }
+    else
+    {
+        // Print ALSA PCM device name outside of _CheckFormat() function (that is, it is actually being used).
+        HXLOGL4(HXLOG_ADEV, "Opening ALSA PCM device, %s, for actual use!", szDevice);
+        printf("Opening ALSA PCM device %s\n", szDevice);
+    }

I think those should be L2 log statements. It would be helpful to have
those when trying to debug a player out in the field (you only get L1
and L2 in release builds).

-
+        // Output to stdout too because the code is still quite new.
+        printf("Device Configured:\n");
+        printf("         Sample Rate: %u\n",  (unsigned int) m_unSampleRate);
+        printf("        Sample Width: %u\n",  (unsigned int) m_uSampFrameSize);
+        printf("        Num channels: %u\n",  (unsigned int) m_unNumChannels);
+        printf("          Block size: %d\n",  m_wBlockSize);
+        printf("  Device buffer size: %lu\n", (unsigned long int) m_ulDeviceBufferSize);
+        printf("   Supports HW Pause: %d\n",  m_bHasHardwarePauseAndResume);
+        printf("     Start threshold: %d\n",  (int) start_threshold);
+        printf("\n");
+        fflush(stdout);

only do the above in _DEBUG builds....


+    if(state == SND_PCM_STATE_XRUN)
+    {
+        HXLOGL1 ( HXLOG_ADEV, "XRUN in GetBytesActuallyPlayedUsingDelay()");
+    }
...
      if (err < 0)
      {
-        HXLOGL1 ( HXLOG_ADEV, "snd_pcm_status: %s", snd_strerror(err));
+        HXLOGL1 ( HXLOG_ADEV, "snd_pcm_delay: %s", snd_strerror(err));
+    }
+    else if (frame_delay < 0)
+    {
+        HXLOGL1 ( HXLOG_ADEV, "XRUN! frame_delay: %d", frame_delay);
+        nBytesPlayed = m_ulTotalWritten;
+        retVal = HXR_OK; // Is this really OK?
      }


Since those are L1 logs, make sure they only fire during important
error conditions. L1s should fire very rarely or just at startup.

-//    HXLOGL4 ( HXLOG_ADEV, "nBytesPlayed: %llu, m_ulTotalWritten: %llu\n", nBytesPlayed, m_ulTotalWritten);
+    HXLOGL2 ( HXLOG_ADEV, "GetBytesActuallyPlayedUsingDelay()  nBytesPlayed: %llu,   m_ulTotalWritten: %llu \n", nBytesPlayed, m_ulTotalWritten);


This looks like it should *NOT* be a L2, L1 and L2 are in all release builds.
They should not fire all the time. Also, don't leave code in that is
commented out, just remove it unless it is really needed to understand
the code.

+                // Add AlsaVaryingSampleRate into Preference.
+                IHXBuffer* pBuffer = new CHXBuffer;
+                pBuffer->AddRef();
+                pBuffer->SetSize(2);
+                SafeSprintf((char*) pBuffer->GetBuffer(),2,"%d", 0); /* Flawfinder: ignore */
+                z_pIHXPrefs->WritePref("AlsaVaryingSampleRate", pBuffer);
+                pBuffer->Release();
+            }

this seems like overkill. I think you can just do:

   WritePrefUINT32( m_pContext, "AlsaVaryingSampleRate", 0 );




Not really part of this CR, but what happens if a user selects ALSA as
the output system and they do not have it installed?

--greg.

From gwright at real.com  Tue Oct 24 11:47:44 2006
From: gwright at real.com (Greg Wright)
Date: Tue Oct 24 12:59:50 2006
Subject: [Player-dev] CR-Client: Changing Volume Control to not touch
	system volume; Software Volume Control (#2)
In-Reply-To: <6.2.1.2.2.20061024093431.3a2f0270@mailone.real.com>
References: <6.2.1.2.2.20061024093431.3a2f0270@mailone.real.com>
Message-ID: <453E5FD0.1020704@real.com>

Daniel Yek wrote:
> 
> Modified by: dyek@real.com
> Date: 10/24/2006
> Project: Helix Player
> 
> Synopsis: Helix Player was changing the System/PCM/Device Volume and users
>   expressed desire for application volume control to not influence system
>   volume. This is another fix.
> 
> Overview:
>   This is the previous CR.
>   
> http://lists.helixcommunity.org/pipermail/player-dev/2006-September/002491.html 
> 
> 
>   We have changed the approach used to address this problem.
>   In this patch, we are sticking to volume control interface returned by:
>     3. Audio device volume control = IHXAudioPlayer::GetDeviceVolume()
> 
>   GetDeviceVolume() was used in the released players.
>   Until now, this volume control has been the:
>     system audio device volume control
>   which is ALSA's PCM device.
> 
>   This patch turns this device Volume Control into:
>     Helix audio device volume control
>   This one being software volume control.
> 
>   This patch utilizes Helix Gaintool to attenuate the volume. (Despite 
> the name.)
>   Gaintool changes the audio volume smoothly, without introducing abrupt
>   changes.
> 
>   Also, by implementing the software volume control in Helix's ALSA device
>   code, the response delay is capped to about 0.3 second with smooth 
> changes
>   extends slightly beyond 0.6 second.
>   In other words, this is a much better implementation than I was 
> originally
>   set to work on. (The delay is capped and Gaintool is utilized.)
> 
>   When the player volume is set to 100, and when Gaintool has came to the
>   steady state, audio data is then sent directly to the system audio 
> device by
>   passing Gaintool processing.
>   That means that the user always get the best audio quality when the 
> volume
>   is set to 100, (which corresponds 100% of the system volume,) and then 
> the
>   system-provided volume control is used to set the desired volume control,
>   because no change of audio data occurs -- Gaintool not processing it.
> 
>   Volume saving and restoring is implemented using the "volume" preference.
> 
>   This fix only implement software volume control in Helix's ALSA device 
> code,
>   not in OSS. When the volume control preference is set to OSS, the volume
>   control still changes system volume.
> 
> 
> Files Modified:
> audio/device/platform/unix/audlinux_alsa.cpp  - Implement Software Volume
>     Control and Gaintool interface code.
> audio/device/platform/unix/audlinux_alsa.h    - Member variables, macros.
> 
> player/hxclientkit/src/CHXClientPlayer.cpp    - "volume" preference.
> player/hxclientkit/src/CHXClientPlayer.h      - Member variable for 
> engine callback.
> 
> audio/device/auddevlib_linux2.pcf - Added gain.h include path.
> audio/gaintool/gain.c       - Added gainIsSteadyState().
> audio/gaintool/pub/gain.h   - Added gainIsSteadyState().
> client/audiosvc/pub/mixengine.h - Move static utility member functions 
> to public.
> 
> 
> Platforms and Profiles Affected:
> Linux
> 
> Platforms and Profiles Build Verified:
> Profile: helix_client_all_define
> Platform: Fedora Core 5
> 
> Platforms and Profiles Functionality verified:
> Profile: helix_client_all_define
> Platform: Fedora Core 5
> 
> Branch: HEAD
> 
> Copyright assignment: I am a RealNetworks employee.

I am only looking at the core parts (no hxclientkit or player modules)....




+        free(m_pGaintoolBuffer);
+        m_pGaintoolBuffer = NULL;

You may find it easier to do HX_FREE(m_pGaintoolBuffer). If you are in
the habit of using the HX_* macros, it is much harder to forget to
NULL a member var out.


If HELIX_FEATURE_GAINTOOL is not defined, do we revert to the old
behavior? Some mobile builds will not include HELIX_FEATURE_GAINTOOL
but will use ALSA.

+                free(pOrig);
+                m_nGaintoolBufferLength = 0;

It is always good practice to NULL out a free'ed var (pOrig=NULL).

+HXBOOL gainIsSteadyState(GAIN_STATE* g);
+

you cold make that inline....

--greg.




From dyek at real.com  Tue Oct 24 17:24:35 2006
From: dyek at real.com (Daniel Yek)
Date: Tue Oct 24 18:32:57 2006
Subject: [Player-dev] Re: [Helix-client-dev] CR-Client: Support multi-channel
 playback on	Linux using ALSA
In-Reply-To: <453E5C48.7030205@real.com>
References: <6.2.1.2.2.20061024070838.3968e798@mailone.real.com>
	<453E5C48.7030205@real.com>
Message-ID: <6.2.1.2.2.20061024164226.3a72fa78@mailone.real.com>

Thanks, Greg, for the quick review.

I am responding to some of them below and will follow up more later.

At 11:32 AM 10/24/2006, Greg Wright wrote:

>>   Note that on some mis-configured system, "plug:surround51" was defined 
>> even though
>>   the system isn't 5.1 capable. This is system configuration problem.
>>   On such system, ALSA would invoke the "plug" plugin, which uses 
>> "route" plugin to
>>   discard surround sound content and playback in 2-channel mode.
>>   On these systems, we really want to have Helix client "preserve" all 
>> channels by
>>   down-mixing it to 2 channels.
>
>So, do we properly handle mis-configured systems? If not, we should. At
>least we should have a pref that will let users force 2-channel playback,
>if we don't already.

I was/am planning to do just that. I'm working on that now.


>>(3)
>>   ALSA now always configures the sound card to 48000Hz.
>>   So, Helix's ALSA audio device _CheckFormat() code now forces Helix client
>>   to use 48000Hz.
>
>Is this the case for *all* ALSA systems out in the wild?

Yes, more or less. (ALSA default to 48000Hz and for a while, you couldn't 
change that. In the very latest code, there is a configuration setting that 
allows users to deviate from the default. Still the default is 48000Hz.)


>If not, we need to handle that.

This is provided through the "AlsaVaryingSampleRate" preference in this 
patch. So, a user could change this preference entry in the following file 
like this:
~/.hxplayerrc:
AlsaVaryingSampleRate=1

With this, the previous behavior is preserved to use whatever sample rate 
ALSA plug layer is accepting. ALSA's plug layer would then resample to 
48000Hz before sending it to the device.

>I am only reviewing the core parts below. In the future you should break 
>up the CR so that at least the core parts are seperate.

Will do that in the future.

>(helix-client-dev is never used for CRs,

Good to know. I was looking at the listinfo page and could figure out the 
differences between helix-client-dev and client-dev:
http://lists.helixcommunity.org/mailman/listinfo
Client-dev:       The main list for developers to discuss project 
development issues and requirements for version control.
Helix-client-dev: Main developer discussion list for the Helix DNA Client.

It would be great if the admin could add "Not for Code Review" in 
Helix-client-dev entry. I'll email the admin.



>-    virtual HX_RESULT _OpenAudio() = 0;
>+    virtual HX_RESULT _OpenAudio( const HXAudioFormat* pFormat ) = 0;
>
>I am not sure I like changing this in audUnix.h.

I don't have strong preference. It is much easier for me to not change the 
function prototype, but trouble-shooting became more tricky. You never know 
when the format information is set in the member variables with so many 
_CheckFormat() calls that do _OpenAudio() to test the ALSA. Those member 
variables surely sounded like "global variables".

I can do it either way.


>If you do, you need
>to change it everywhere, not just ALSA and OSS:
>
>D:\cygwin\home\gwright\helix\audio\device\pub\platform\openwave\audopwave.h(205): 
>virtual HX_RESULT _OpenAudio();
>D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audhpux.h(100): 
>virtual HX_RESULT _OpenAudio();
>D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audirix.h(100): 
>virtual HX_RESULT _OpenAudio();
>D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audlinux_esound.h(118): 
>virtual HX_RESULT _OpenAudio();
>D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audSolaris.h(102): 
>virtual HX_RESULT _OpenAudio();
>D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audUnix.h(221): 
>virtual HX_RESULT _OpenAudio() = 0;
>D:\cygwin\home\gwright\helix\audio\device\pub\platform\unix\audusound.h(100): 
>virtual HX_RESULT _OpenAudio();

I'm aware of this. I was intending to change those function prototypes when 
I commit the patch.


>I think it would be better, since they all inherit from audUnix, that you
>just store the format in a member var (maybe a new one in audUnix) and
>let the child classes use it. So, in _OpenAudio they already have the
>format in, for example, m_pAudioFormat.

Do you think member variable is better?


>-
>+        // Output to stdout too because the code is still quite new.
>+        printf("Device Configured:\n");
>+        printf("         Sample Rate: %u\n",  (unsigned int) m_unSampleRate);
>+        printf("        Sample Width: %u\n",  (unsigned int) 
>m_uSampFrameSize);
>+        printf("        Num channels: %u\n",  (unsigned int) 
>m_unNumChannels);
>+        printf("          Block size: %d\n",  m_wBlockSize);
>+        printf("  Device buffer size: %lu\n", (unsigned long int) 
>m_ulDeviceBufferSize);
>+        printf("   Supports HW Pause: %d\n",  m_bHasHardwarePauseAndResume);
>+        printf("     Start threshold: %d\n",  (int) start_threshold);
>+        printf("\n");
>+        fflush(stdout);
>
>only do the above in _DEBUG builds....

Will do.


>+                // Add AlsaVaryingSampleRate into Preference.
>+                IHXBuffer* pBuffer = new CHXBuffer;
>+                pBuffer->AddRef();
>+                pBuffer->SetSize(2);
>+                SafeSprintf((char*) pBuffer->GetBuffer(),2,"%d", 0); /* 
>Flawfinder: ignore */
>+                z_pIHXPrefs->WritePref("AlsaVaryingSampleRate", pBuffer);
>+                pBuffer->Release();
>+            }
>
>this seems like overkill. I think you can just do:
>
>   WritePrefUINT32( m_pContext, "AlsaVaryingSampleRate", 0 );

Great! That would make it much simpler. I'll try it.


>Not really part of this CR, but what happens if a user selects ALSA as
>the output system and they do not have it installed?

Good question. How can I test this...

I think alsa-libs (linked into the executable) would open the device 
special file and fail. I don't exactly know what would happen, but I 
believe that all ALSA API calls, snd_*, would fail. snd_pcm_open() would 
fail with RA_AOE_BADOPEN and you might know what happen from there better 
than I do, but I think I saw a popup in the player saying that the audio 
device is busy and try again later, or something like that.



-- 
Daniel Yek


From dyek at real.com  Wed Oct 25 14:46:17 2006
From: dyek at real.com (Daniel Yek)
Date: Wed Oct 25 15:54:25 2006
Subject: [Player-dev] CR-Client: Changing Volume Control to not touch system
 volume; Software Volume Control (#2)
In-Reply-To: <453E5FD0.1020704@real.com>
References: <6.2.1.2.2.20061024093431.3a2f0270@mailone.real.com>
	<453E5FD0.1020704@real.com>
Message-ID: <6.2.1.2.2.20061025134205.4204b568@mailone.real.com>

So, the core part for this (one) CR is done. I'll commit this after my 
other CR is committed (easier for me).

Comment inline.

At 11:47 AM 10/24/2006, Greg Wright wrote:
>+        free(m_pGaintoolBuffer);
>+        m_pGaintoolBuffer = NULL;
>
>You may find it easier to do HX_FREE(m_pGaintoolBuffer). If you are in
>the habit of using the HX_* macros, it is much harder to forget to
>NULL a member var out.

Thanks. I changed it to use HX_FREE().


>If HELIX_FEATURE_GAINTOOL is not defined, do we revert to the old
>behavior? Some mobile builds will not include HELIX_FEATURE_GAINTOOL
>but will use ALSA.

Yes.


>+                free(pOrig);
>+                m_nGaintoolBufferLength = 0;
>
>It is always good practice to NULL out a free'ed var (pOrig=NULL).

pOrig is a local variable. The original member variable is NULL-ed in this 
case when realloc() returned NULL.


>+HXBOOL gainIsSteadyState(GAIN_STATE* g);
>+
>
>you cold make that inline....

I would agree except that in this case, GAIN_STATE is a hidden struct 
defined in gain.c, so gain.h doesn't know the fields in the struct.



>--greg.

-- 
Daniel Yek


From dyek at real.com  Wed Oct 25 17:37:49 2006
From: dyek at real.com (Daniel Yek)
Date: Wed Oct 25 18:46:00 2006
Subject: [Player-dev] CR-Client: Support multi-channel playback on Linux
	using ALSA
In-Reply-To: <6.2.1.2.2.20061024164226.3a72fa78@mailone.real.com>
References: <6.2.1.2.2.20061024070838.3968e798@mailone.real.com>
	<453E5C48.7030205@real.com>
	<6.2.1.2.2.20061024164226.3a72fa78@mailone.real.com>
Message-ID: <6.2.1.2.2.20061025172236.45395748@mailone.real.com>

This is the player part of the new CR. The previous CR (was adding only a 
new ALSA PCM 5.1 Device text entry) can be ignore.

All changes are in the GUI of Preference dialog box.

I have removed the mixer device text entries in the Preference dialog box 
and added a new checkbox to Force stereo playback. The original addition of 
ALSA PCM 5.1 Device text entry remains there.


At 05:24 PM 10/24/2006, Daniel Yek wrote:
>>>   Note that on some mis-configured system, "plug:surround51" was 
>>> defined even though
>>>   the system isn't 5.1 capable. This is system configuration problem.
>>>   On such system, ALSA would invoke the "plug" plugin, which uses 
>>> "route" plugin to
>>>   discard surround sound content and playback in 2-channel mode.
>>>   On these systems, we really want to have Helix client "preserve" all 
>>> channels by
>>>   down-mixing it to 2 channels.
>>
>>So, do we properly handle mis-configured systems? If not, we should. At
>>least we should have a pref that will let users force 2-channel playback,
>>if we don't already.
>
>I was/am planning to do just that. I'm working on that now.

This is now handled by the "DisableSurroundSoundPlayback" preference.

If a system's surround sound playback isn't working, use:
~/.hxplayrc:
DisableSurroundSoundPlayback=1

That would force all channels to be merged into 2 channels (stereo).

I have provided a checkbox in the players' Preference Dialog box too.



>>>(3)
>>>   ALSA now always configures the sound card to 48000Hz.
>>>   So, Helix's ALSA audio device _CheckFormat() code now forces Helix client
>>>   to use 48000Hz.
>>
>>Is this the case for *all* ALSA systems out in the wild?
>
>Yes, more or less. (ALSA default to 48000Hz and for a while, you couldn't 
>change that. In the very latest code, there is a configuration setting 
>that allows users to deviate from the default. Still the default is 48000Hz.)
>
>
>>If not, we need to handle that.
>
>This is provided through the "AlsaVaryingSampleRate" preference in this 
>patch. So, a user could change this preference entry in the following file 
>like this:
>~/.hxplayerrc:
>AlsaVaryingSampleRate=1
>
>With this, the previous behavior is preserved to use whatever sample rate 
>ALSA plug layer is accepting. ALSA's plug layer would then resample to 
>48000Hz before sending it to the device.
>

-- 
Daniel Yek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cr.new.surroundSound.player[1].tgz
Type: application/octet-stream
Size: 33011 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/player-dev/attachments/20061025/bc8fa748/cr.new.surroundSound.player1-0001.obj
From bobclark at real.com  Wed Oct 25 18:10:15 2006
From: bobclark at real.com (Bob Clark)
Date: Wed Oct 25 19:20:01 2006
Subject: [Player-dev] CR-Client: Changing Volume Control to not
	touch system volume; Software Volume Control (#2)
In-Reply-To: <6.2.1.2.2.20061024093431.3a2f0270@mailone.real.com>
References: <6.2.1.2.2.20061024093431.3a2f0270@mailone.real.com>
Message-ID: <6.2.1.2.2.20061025180914.03669618@mailone.real.com>

The player/hxclientkit part of this diff looks good. Could you also 
checkout out player/hxclientkit from hxclient_1_5_0_cayenne and apply these 
changes to that branch as well?

--Bob

At 09:37 AM 10/24/2006, Daniel Yek wrote:

>Modified by: dyek@real.com
>Date: 10/24/2006
>Project: Helix Player
>
>Synopsis: Helix Player was changing the System/PCM/Device Volume and users
>   expressed desire for application volume control to not influence system
>   volume. This is another fix.
>
>Overview:
>   This is the previous CR.
> 
>http://lists.helixcommunity.org/pipermail/player-dev/2006-September/002491.html
>
>   We have changed the approach used to address this problem.
>   In this patch, we are sticking to volume control interface returned by:
>     3. Audio device volume control = IHXAudioPlayer::GetDeviceVolume()
>
>   GetDeviceVolume() was used in the released players.
>   Until now, this volume control has been the:
>     system audio device volume control
>   which is ALSA's PCM device.
>
>   This patch turns this device Volume Control into:
>     Helix audio device volume control
>   This one being software volume control.
>
>   This patch utilizes Helix Gaintool to attenuate the volume. (Despite 
> the name.)
>   Gaintool changes the audio volume smoothly, without introducing abrupt
>   changes.
>
>   Also, by implementing the software volume control in Helix's ALSA device
>   code, the response delay is capped to about 0.3 second with smooth changes
>   extends slightly beyond 0.6 second.
>   In other words, this is a much better implementation than I was originally
>   set to work on. (The delay is capped and Gaintool is utilized.)
>
>   When the player volume is set to 100, and when Gaintool has came to the
>   steady state, audio data is then sent directly to the system audio 
> device by
>   passing Gaintool processing.
>   That means that the user always get the best audio quality when the volume
>   is set to 100, (which corresponds 100% of the system volume,) and then the
>   system-provided volume control is used to set the desired volume control,
>   because no change of audio data occurs -- Gaintool not processing it.
>
>   Volume saving and restoring is implemented using the "volume" preference.
>
>   This fix only implement software volume control in Helix's ALSA device 
> code,
>   not in OSS. When the volume control preference is set to OSS, the volume
>   control still changes system volume.
>
>
>Files Modified:
>audio/device/platform/unix/audlinux_alsa.cpp  - Implement Software Volume
>     Control and Gaintool interface code.
>audio/device/platform/unix/audlinux_alsa.h    - Member variables, macros.
>
>player/hxclientkit/src/CHXClientPlayer.cpp    - "volume" preference.
>player/hxclientkit/src/CHXClientPlayer.h      - Member variable for engine 
>callback.
>
>audio/device/auddevlib_linux2.pcf - Added gain.h include path.
>audio/gaintool/gain.c       - Added gainIsSteadyState().
>audio/gaintool/pub/gain.h   - Added gainIsSteadyState().
>client/audiosvc/pub/mixengine.h - Move static utility member functions to 
>public.
>
>
>Platforms and Profiles Affected:
>Linux
>
>Platforms and Profiles Build Verified:
>Profile: helix_client_all_define
>Platform: Fedora Core 5
>
>Platforms and Profiles Functionality verified:
>Profile: helix_client_all_define
>Platform: Fedora Core 5
>
>Branch: HEAD
>
>Copyright assignment: I am a RealNetworks employee.
>
>
>
>
>--
>Daniel Yek
>
>
>
>_______________________________________________
>Player-dev mailing list
>Player-dev@helixcommunity.org
>htt