title: Correct Media Type settings for a DirectShow filter that delivers Wav audio data?
body: <p>I am using Delphi 6 Pro with the DSPACK DirectShow component library to create a DirectShow filter that delivers data in Wav format from a custom audio source.  Just to be very clear, I am delivering the raw PCM audio samples as Byte data.  There are no Wave files involved, but other Filters downstream in my Filter Graph expect the output pin to deliver standard WAV format sample data in Byte form.</p>
  
  <p>Note: When I get the data from the custom audio source, I format it to the desired number of channels, sample rate, and bits per sample and store it in a TWaveFile object I created.  This object has a properly formatted TWaveFormatEx data member that is set correctly to reflect the underlying format of the data I stored.</p>
  
  <p>I don't know how to properly set up the MediaType parameter during a GetMediaType() call:</p>
  
  <pre><code>    function TBCPushPinPlayAudio.GetMediaType(MediaType: PAMMediaType): HResult;
  
      .......
  
      with FWaveFile.WaveFormatEx do
      begin
          MediaType.majortype                 := (1)
          MediaType.subtype                   := (2)
          MediaType.formattype                := (3)
          MediaType.bTemporalCompression      := False;
          MediaType.bFixedSizeSamples         := True;
          MediaType.pbFormat                  := (4)
          // Number of bytes per sample is the number of channels in the
          //  Wave audio data times the number of bytes per sample
          //  (wBitsPerSample div 8);
          MediaType.lSampleSize := nChannels * (wBitsPerSample div 8);
      end;
  </code></pre>
  
  <p>What are the correct values for (1), (2), and (3)?  I know about the MEDIATYPE_Audio, MEDIATYPE_Stream, and MEDIASUBTYPE_WAVE GUID constants, but I am not sure what goes where.</p>
  
  <p>Also, I assume that I need to copy the WaveFormatEx stucture/record from the my FWaveFile object over to the pbFormat pointer (4).  I have two questions about that:</p>
  
  <p>1) I assume that should use CoTaskMemAlloc() to create a new TWaveFormatEx object and copy my FWaveFile object's TWaveFormatEx object on to it, before assigning the pbFormat pointer to it, correct?</p>
  
  <p>2) Is TWaveFormatEx the correct structure to pass along?  Here is how TWaveFormatEx is defined:</p>
  
  <pre><code>tWAVEFORMATEX = packed record
      wFormatTag: Word;       { format type }
      nChannels: Word;        { number of channels (i.e. mono, stereo, etc.) }
      nSamplesPerSec: DWORD;  { sample rate }
      nAvgBytesPerSec: DWORD; { for buffer estimation }
      nBlockAlign: Word;      { block size of data }
      wBitsPerSample: Word;   { number of bits per sample of mono data }
      cbSize: Word;           { the count in bytes of the size of }
  </code></pre>
  
  <p>end;</p>
  
  <p><strong>UPDATE: 11-12-2011</strong></p>
  
  <p>I want to highlight one of the comments by @Roman R attached to his accepted reply where he tells me to use <strong>MEDIASUBTYPE_PCM</strong> for the sub-type, since it is so important.  I lost a significant amount of time chasing down a DirectShow "<em>no intermediate filter combination</em>" error because I had forgotten to use that value for the sub-type and was using (incorrectly) <strong>MEDIASUBTYPE_WAVE</strong> instead.  MEDIASUBTYPE_WAVE is incompatible with many other filters such as system capture filters and that was the root cause of the failure.  The bigger lesson here is if you are debugging an inter-Filter media format negotiation error, make sure that the formats between the pins being connected are <strong>completely</strong> equal.  I made the mistake during initial debugging of only comparing the WAV format parameters (format tag, number of channels, bits per sample, sample rate) which were identical between the pins.  However, the difference in sub-type due to my improper usage of MEDIASUBTYPE_WAVE caused the pin connection to fail.  As soon as I changed the sub-type to MEDIASUBTYPE_PCM as Roman suggested the problem went away.</p>