Beginning Game Audio Programming [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Beginning Game Audio Programming [Electronic resources] - نسخه متنی

Mason McCuskey

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
توضیحات
افزودن یادداشت جدید


DIRECTX AUDIO BASICS

I know youre probably dying to get to some sample code, but there are a few conceptual things you need to know first. Thats what this first section is all about. Youll get to the code in the next section.


DirectMusic, DirectSound, or DirectX Audio?


In the beginning, there was DirectSound. Then there was DirectMusic. And then, just when you thought it was safe, Microsoft (in DirectX 8) introduced a third name: DirectX Audio.

Whats unfortunate is two out of the three terms are misnomers. You can play sound effects using DirectMusic, and you can play music using DirectSound. Funny how that works, isnt it? Your sanity will last longer if you think of these interfaces not in terms of, "Okay, this ones for sound effects, and this ones for music," rather, in terms of low-level and high-level APIs. Table 2.1 summarizes the differences between these three terms.




















Table 2.1: Definitions of DirectX Audio Terms.

DirectWord


Meaning


DirectSound


The low-level audio API for Windows. This API concerns itself with the minutia of getting raw sound bytes in and out of the sound card.


DirectMusic


The high-level audio API. This API takes a step back and allows you to say things like, "Okay, Im not sure if this is a WAV file, a MIDI file, or a SGT (dynamic music segment) file, but I want you to load it and play it."


DirectX Audio


Microsofts name for the audio API as a whole—the house in which DirectSound and DirectMusic live.



The giant invisible Microsoft hand is pushing us all to use DirectMusic as "the" audio API. As of DirectX 9 it is still possible to talk directly to the low-level API (DirectSound); however, it is very common to use just the DirectMusic routines and never bother with the low-level DirectSound API (unless you want low-level control over your WAV files). I wouldnt be surprised if in the future Microsoft sealed off the DirectSound API and made the DirectMusic API the only interface available in DirectX Audio.

However, the rest of this chapter will focus on DirectSound, not because its easier than DirectMusic or that its the better way to go, but simply because DirectSound allows you to strip away a lot of the layers Microsoft built and deal directly with sending bytes to the sound card. For people new to game audio programming, this is the simplest possible example, and for people experienced with game audio, its probably the method with which theyre most familiar.


Primary and Secondary Buffers


At its core, DirectSound relies on the concepts of primary and secondary buffers. A buffer in this case is a 1D array of bytes that will eventually become audio (as explained in the last chapter).

Each application has exactly one Primary DirectSound buffer. This is easy—whats in the primary buffer is what comes out of the speakers, period.

An application needs at least one, but can have as many Secondary DirectSound buffers as it wants. Secondary buffers hold a single sound or stream of audio data.

These buffers fit together as illustrated by Figure 2.1. Essentially, you store your various sounds in secondary buffers, and then mix them together into the primary buffer. Usually, DirectSound handles the mixing, so you never actually touch the primary buffer yourself. However, you can gain access to it, but keep in mind that if you want direct access to the primary buffer (to do your own mixing), you cant create any secondary buffers. But, unless youre doing something very strange, you wont want to do this.


Figure 2.1: DirectX Audio mixes secondary buffers into the primary buffer, then out to your speakers.

Additionally, buffers can be created in hardware or in software. A hardware buffer lives on the sound cards RAM, whereas a software buffer lives in system memory.





Tip

Nowadays, theres no real difference between hardware buffers and software buffers. Way back in the nineties, PCs had a very slow ISA bus. So slow, in fact, that it was often better for sound cards to store commonly used sounds in their own RAM, located on the sound card itself. That way, when the audio chip needed to mix a sound, it wouldnt have to transfer all those bytes over the slow ISA bus.

Todays PCI bus is much faster, to the point where it no longer makes sense for sound cards to have their own RAM—everything is stored in system memory and transferred over the wicked-fast PCI bus when needed. The PCI bus has more than enough bandwidth for audio data (though its still a bit too slow for graphics data, which is why you see video cards with on-board RAM).

Im glossing over this terribly; if you want a more technical explanation, read the MSDN article, "Sound Cards,Voice Management, and Driver Models," by Brian Schmidt, available at

http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnaudio/html/ntk_sc.asp.



Streaming


Okay, so you know that sound effects go in secondary buffers. But what happens when the secondary buffer is too small to hold the whole sound effect? For example, if you want to play digitized music for a 15-minute in-game cut scene, you cant just load the whole 15 minutes of audio data into memory all at once (well, maybe you could, but thatd be silly, and it would take up a lot of memory). A better solution is to load the portion of audio data you need right before its needed—in other words, to stream it off the disk.

Streaming is a common technique that works very well (thanks mostly to the fact that a hard drive or CD-ROM drive can read bytes much faster than a speaker plays them). Youll become more familiar with streaming as this book goes on; for now, just understand the concept, as illustrated by Figure 2.2.


Figure 2.2: Streaming a big sound file requires loading pieces of it just as theyre needed.

When you stream audio data, instead of loading all of the data into memory at once, you treat your secondary buffer as a window scrolling over your sound data and load the data as you need it. For example, in Figure 2.2, you see that ten seconds of audio data (the beginning of a 3-minute song) have been loaded into the buffer. The code then instructs the buffer to start playing, and the song starts to play. As the song is played, the computer reads new data from the disk and places it in the buffer, right behind the play cursor, overwriting the data thats just been played. Eventually, the play cursor wraps around to the start of the buffer and starts playing the new data. Things continue this way until all data has been played.

Obviously this whole setup depends on being able to read data faster than you can play it. Happily, hard drives today can read bytes much faster than the speaker can play them.

/ 127