Kevin,

My comments:

1. This looks like it is commented out - is that correct?

@@ -1818,7 +1839,7 @@
          pInfo->llStartTimeInSamples,pInfo->llEndTimeInSamples,
          nn,
          nMixbufferOffset,nMixbufferOffset+nSamplesToUse,nSamplesToUse);
-     fprintf(f1,"  pastPacketStart = %I64d, nMixbufferOffset = %ld\n",
+     fprintf(f1,"  pastPacketStart = %ld, nMixbufferOffset = %ld\n",
                 pastPacketStart,nMixbufferOffset) ;
      fclose(f1);}
 */

  Are there any new logging statements that should be added
  as part of this new code?

2. Just wondering - why do we have to change the thread priority?

@@ -356,13 +392,14 @@
            delete[] aPositionNotify;
            DWORD dwWaitThreadID(0);
            m_hWaitThread = CreateThread(NULL, 0, EventThreadProc, 
(LPVOID)this, 0, &dwWaitThreadID);
+           SetThreadPriority( m_hWaitThread, THREAD_PRIORITY_HIGHEST );
        }
        HX_RELEASE(pNotify);
 
3. All BOOLs should be changed to HXBOOL, unless they
   specifically need the Windows BOOL.


Rest looks good.

Eric 

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Ross
> Sent: Tuesday, May 03, 2005 1:47 AM
> To: [EMAIL PROTECTED]; 
> [EMAIL PROTECTED]
> Subject: [Audio-dev] CR-Client: Implement opaque stream 
> support (for SecureAudio Path)
> 
> Synopsis:
> Implement opaque streams, which will be used initially by 
> Secure Audio Path.
>  
> Overview:
> Secure Audio Path (SAP) is used by certain DRM content, in 
> which the audio
> data is fed to our application in an encrypted state, and is 
> decrypted by
> the audio driver.  Therefore, our app must not do anything to 
> modify the
> data during its journey through the core.
>  
> This is implemented by adding the concept of an opaque audio 
> stream.  New
> header values were added to the audio stream to signify this 
> is an opaque
> stream.  Audio services will see this header, and go into an 
> "opaque mode".
> This causes audio services to allow only one stream, and no 
> modifications
> may be done to it (no up/down mix, no pre- or post-mix hooks, 
> etc).  Also,
> the audio device will be opened in an opaque mode, passing to 
> it any special
> data needed for this type of opaque stream.  For SAP, this is a custom
> WAVEFORMATEX header with which the audio device must be opened.
> 
> Files Modified:
> client/audiosvc/hxaudses.cpp/.h:  Add flag for opaque mode, 
> opens audio
> device in opaque mode if needed, disables post-mix hooks in 
> opaque mode
> client/audiosvc/hxaudstr_new.cpp/.h: Read audio stream 
> headers for opaque
> mode, sets audio session to opaque mode if needed
> client/audiosvc/mixengine.cpp/.h: Disables modifications to 
> audio data if in
> opaque mode
> common/include/hxausvc.h and hxiids.h: Add new interface
> IHXOpaqueAudioDevice
> audio/device/hxaudev.cpp/.h: Implement IHXOpaqueAudioDevice interface.
> Calls derived _Imp_OpaqueOpen in platform-specific audio device
> audio/device/platform/win/hxaudevds.cpp/.h: Implemented 
> opaque mode, uses
> passed-in WAVEFORMATEX struct instead of building one when in 
> opaque mode,
> also disables real-time hooks.
> 
> Image Size and Heap Use impact:
> Didn't measure, shouldn't add more than 1K total for image 
> size and heap
> use.
> 
> Platforms and Profiles Affected:
> All
> 
> Distribution Libraries affected:
> none
>  
> Distribution library impact and planned action:
> none
>  
> -----------------------------------------------------------
>  
> Platforms and Profiles Build Verified:
> win32-i386-vc7, helix-client-all-defines
> 
> Platforms and Profiles Functionality verified:
> win32-i386-vc7, helix-client-all-defines
> 
> Branch:
> neptune 116, 123, 150, and HEAD (I think that's all)
> 
> QA Instructions:
> A seperate test plan has been written
> 


_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev

Reply via email to