Looking for books on XAct audio

I cannot find books about XAct audio outside of the realm of C#. I know Microsoft wants to pretend that C# is good enough for games but quite honestly it's not and I'm not switching over.

Does anyone know of any books about using XAct audio from C++?

I'm half tempted to move completely away from DirectX as Microsoft has turned it into a C# wannabe club all in the name of using their language. Some of us actually want to move beyond 3D tic tac toe or battleship. I don't want to use C# to code my games and I don't need to. With all of this bloat coming up I may resort to writing my own sound engine and perhaps utilize some OpenAL in it.

I just fail to understand where all of this C/C++ is evil crap comes from. The ONLY time I could ever see a definite leak happening is if allocation is done inside of a constructor and then later that constructor throws. However boost and std::auto_ptr have resolved this issue so I fail to see the big deal. C/C++ is so fast and yet others continually try to move us in a direction that just leads to more bloat. I don't get it.

Maybe Vista was written in C# and Aero in XNA. That would explain why it's so slow and crappy.

It seems to me the DirectX documentation has enough to get started. I haven't started with audio yet but the documentation seems to be written in c and c++. I have looked at the XACT samples and I know they contain audio, again I haven't really looked at it though (edit: the audio portion that is).

Concerning C#, in the latest (or the one before) version of DirectX they took out all the managed documentation. For the exact reasons you were stating, because it was in fact deprecated, but the documentation was pushing it.

I'm not sure I will use XAct or OpenAL. To maintain compatibility I may simply use the multimedia API within the Windows API. I will have to do some old school mixing and loading but it's not too hard.

The basic scheme seems to be:

1. Open audio device and specify callback
2. Load data into audio blocks (buffers)
3. Mix set portion of all audio blocks into one primary audio block
4. Write (play) data of first half of primary audio block, load into second block
4. Callback function is called when driver is done with audio block.
5. At this point, send the second block, load first, mix, etc.

This is very similar to old school DOS when you did this:

1. Retrieve port and interrupt values from BLASTER environment variable.
2. Program DMA for the transfer size (usually auto-init DMA)
3. Program the PIC using the correct interrupt mask
4. Program the DSP for the HALF of the transfer
5. Write an interrupt handler for interrupt specified in BLASTER variable
6. Load data into audio buffers
7. Mix set portion of all audio blocks into one primary audio block and send to DSP
8. When DSP is done it will fire a hardware interrupt on the interrupt specified in BLASTER
9. Inside interrupt handler play block that was just loaded and load into block that just played.
10. Continue ad nauseum.


Essentially this is the mixing:

Code:

---

...
struct Sample16
{
  unsigned int *buffer;
  unsigned int sample_length;
  unsigned int fade_out_start;
  unsigned int fade_out_length;
};
...
...
float fade = 0.0f;
for (int i = 0;i < mix_buffer_size; ++i)
{
  unsigned int play_offset = play_cursor + i;
  unsigned int sample_value = samples[num_sample].buffer[play_offset];
  unsigned int fade_out_start = sample[num_sample].fade_out_start;

  if (play_offset >  fade_out_start)
  {
      fade = ((float)play_offset - (float)fade_out_start) / (float)(sample[num_sample].fade_out_length);
  }

  float final_value = (float)sample_value * fade;

  primary_buffer[current_block_start + i] = static_cast<unsigned int>(value);

  ++num_sample;
}
...
...

---

If my memory serves me right this will fade out a sound as it nears the end so it will not pop or click. The primary buffer is then what is sent to Windows to be played or in DOS would have been the pointer to the memory area that the DMA was programmed for. Since the DMA scanned this memory it then transferred any changes directly to the sound card DSP all without the CPU touching any of the data.

I'm fairly sure I can code this using pure Win32 multimedia calls.