游戏邦注：本文原作者是索尼电脑娱乐的主程序员Nicolas Fournel，他在本文中阐述音频程序员的罕见性，并澄清外界对该职位的误解。

我是音频程序员Nicolas Fournel。在游戏行业中，从事这方面工作的人并不多。你往往会看到团队中有图形、可玩性或物理程序员，但音频程序员实属罕见。事实上，某些小工作室根本没有从事该工作的人，通常由新程序员来完成处理音效引擎中间件的任务（游戏邦注：前端代码似乎是新程序员必须通过的强制性礼仪）。即便某些大公司也只有一个音频程序员，由多个项目和团队共享，或者公司会把此类任务分派给音频兼职人员。

game designer(from videogamescholarships.com)

供不应求

从某种意义上来说，这种稀缺性对我们相对有利，因为需求量远远多于音频程序员实际数量。同时，业界对这个职位以及音频程序员能够给团队带来的潜在利益有所误解。自音频程序员面试时，便开始产生这种误解。

因为音频程序员数量很少，所以求职者的面试官几乎不是这方面的人。求职者在面试时通常会同两类不同的人交谈，即其他游戏程序员和音效设计师或音效总监。这两类人都会询问他们熟悉的问题，侧重点在于求职者是否熟悉编程基础或是否知道如何使用DAW，但这与音频编程本身并没有多大关联。在我的从业生涯中，回答过大量有关3D数字、最优化、多线程和C++技巧的问题，但却从来没有人让我说说各种混响编写法则的优缺点，或者何时应该使用多相滤波器。

更令人感到困惑的是，有些人事专员将“音频工程师”与“音频程序员”混为一谈，这会让你面临需要同时处理来自Bob Katz（游戏邦注：美国顶级Mastering处理大师）崇拜者和软件工程师的求职申请的窘境。有趣的是，我看到日本正在招募些许“音效程序员”，而这些职位实际上涉及的是合成器编程（游戏邦注：在音频部门中为合成器制作补丁）。

那么，音频程序员究竟是个什么样的职位呢？近期Video Games Musician邮件中Brian Schmidt的说法值得参考。他说道，目前游戏行业中有三种有关音频编程的职位——执行程序员、引擎程序员和DSP程序员。

音频程序员的三种类型

执行程序员将音频添加到各种游戏成分中。通常他负责装载和卸载大量音频资料，触发背景音乐、对话或音效（游戏邦注：其中大部分内容有望通过数据驱动完成）。他还负责在必要时对这些元素进行更新，如改变音量和音调等。为完成这些工作，他可以利用工作室内的音频引擎或FMod之类音频中间件。很显然，非音频专才也可以完成这些工作。但是，这是个熟悉游戏代码库的绝佳岗位，因为你很可能需要挖掘所有子系统。

依Schmidt所述，引擎程序员负责编写位于所有低级音频系统之上的层。他可能需要构建在音轨间智能交替演变的互动音乐系统，处理音效实例，限制对话长度等。我更愿意把这些称为对各种音频成分的处理，而不是引擎开发。相对执行程序员而言，这个职位需要对系统编程有更深层次的理解。以上文提到的互动音乐为例，他通常需要处理流动和多线程等问题。此类程序员很可能需要接触某些音效或音乐术语，但该职位仍旧不需要大量音频知识。

最后要说的是最低级的DSP程序员，他需要自行处理音频样例，编写高度优化的混频例行程序、滤波器和混响等。这些人对音频了解更多，知晓快速傅氏变换、有限冲激响应和无限冲激响应滤波器、卷积、无混淆波形生成等。

当然，有些程序员单个人便可以做完以上三种工作，或者可以自行完成将上述工作结合起来的任务。编写音频工具（游戏邦注：比如将音效打包成库，或降低音频与脚本的重复性）是游戏音频开发中另一个非常重要的方面，也是面向运行时间的层次。

音频开发尚未步入正轨

正如你所看到的那样，这三项工作描述显示其涉及音频的程度各不相同。既然可用的游戏音频程序员如此之少，为何不让他们专注于音频设计，而安排他们做些只与音频大致相关的事情呢？我们在上文中描述的执行程序员和中级音频系统开发者并不一定非要音频专业人员。任何游戏程序员都会用音效API来触发音效。编写文件基于某种逻辑（游戏邦注：如互动音乐或对话）流动的系统也是如此。

我深信音频程序员的主要职责和关注点应该是为游戏团队和音效部门面临的问题提供以音频为中心的解决方案，但目前事态并非如此。基于音频分析的新游戏设计方法、游戏运行时产生带有程序音频的音效、知觉声音管理、混频、音频阴影、内容音频工具，这些仅是音频程序员职责的一小部分，然而当代游戏开发却几乎不包含这些方面的内容。这也是为何游戏音效的发展不及图像处理的原因之一。

如果你有个掌握大量音频知识的程序员，却只让他专注于音效触发、音轨流动或某些基础.Net工具，那么机遇正从你身边流失。我会尝试让音频程序员回归音频编程，向外界展示所有我们可以为你、你的音效团队工作流程和游戏做出的贡献。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Opinion: Putting The Audio Back In Audio Programmer

Nicolas Fournel

Nicolas Fournel, principal programmer at Sony Computer Entertainment, talks about the rarity of audio programmers and clears up misconceptions about the role, in this #altdevblogaday-reprinted opinion piece.

Hi, my name is Nicolas and I’m an audio programmer… In the game industry, there are not too many of us. You will always find graphics, gameplay or physics programmers on a team, but audio programmers are a rare breed. Actually, small studios sometimes don’t even have one, and it is often the new guy who will inherit the task of dealing with a middleware sound engine (frontend coding comes a close second as a mandatory rite of passage for new programmers). Even bigger companies may only have one audio programmer who will be shared between various projects and teams, or will be assigned to audio part-time only.

Supply And Demand

In a sense, this scarcity is relatively nice for us, as there usually is a lot more demand than offer. On the other hand, this leads to quite a few misconceptions about the role and what an audio programmer could potentially bring to a team. It starts during the audio programmer’s interview itself.

Since there are so few of us, a candidate is rarely interviewed by his / her peers. Usually he /she will end up talking to two different groups of people: the other game programmers and the sound designers / audio director. Both groups will ask questions about what they are familiar with (and it is important, don’t get me wrong, to have strong basic programming skills, or to know how to use a DAW) but very rarely about audio programming itself. During my career, I have answered numerous questions about 3D maths, optimisation, multithreading, C++ tricks, yet no one ever asked me to give the pros and cons of the various algorithms to write a reverberation, or to say when I should use polyphase filters for example.

Side note: it becomes even more confusing when recruiters throw the term “audio engineer” in the mix and you start receiving applications from both Bob Katz wannabes and software engineers at the same time… Interestingly, I also have seen a few “sound programmers” positions advertised in Japan, which were actually referring to synthesizer programming (i.e. creating patches on synthesizers in the audio department) and not coding.

All that being said, what is the role of an audio programmer then? A recent post by Brian Schmidt (from the Xbox audio hall of fame) on the Video Games Musician’s mailing list gives us a few hints. In the game industry, he said, right now you can find three types of audio-related programming positions: implementation programmer, engine programmer and DSP programmer.

And Then They Were Three

Let’s see what they are doing in a bit more details, shall we?

The implementation programmer will add audio to the various game components. Typically, he will load and unload banks of audio assets, and trigger background music, dialog lines or sound effects (hopefully a lot of that will be data-driven too). He will also update all these elements when needed (e.g. change their volume, pitch, pan etc…). In order to do all that, he will call functions from the in-house audio engine or from some audio middleware such as FMod. Obviously there is no need for him to be an audio wizard to do so. However, it is often a very good position to familiarize yourself with the game’s code base since you will most likely have to dive a bit into all of the sub-systems.

The engine programmer, based on Schmidt’s post, will create a layer that sits on top of the lower level audio system. He may be responsible for building the interactive music system that intelligently crossfades between tracks, for dealing with sound effects instance, limiting dialog queuing etc… I would rather call that working on various audio components than developing an engine, but you get the idea. This position will require a deeper understanding of system programming than the implementer job: for example in the case of the interactive music mentioned above, he will usually have to deal with streaming, multithreading etc… The programmer is also more likely to encounter some sound or musical terminology, but again, an extensive knowledge of audio at this level is hardly needed.

Finally, at the lowest level, DSP programmers will deal with the audio samples themselves: they will write highly optimized mixing routines, filters, reverberations, etc… These guys are the ones who will know more about audio: Fast Fourier Transforms, FIR and IIR filters, convolution, generation of waveforms without aliasing etc…

Of course, sometimes a single programmer will be able to do it all (don’t let him go!) or to do a combination of the tasks described above. Also, this is a very runtime-oriented list: writing audio tools (e.g. to package sound effects into banks, or to make them less repetitive with scripting) is another very important aspect of game audio development.

And The Audio In All That?

As you can see, these three job descriptions show various levels of involvement with audio. Since there are so few game audio programmers available, why not let them work on audio, rather than vaguely audio-related matters? The implementer and the mid-level audio system developer we described above don’t necessarily have to be audio experts. Calling the sound API to trigger sound effects can be done by any game programmer. Writing a system that streams files based on some logic (for interactive music or dialog) as well.

I strongly believe the audio programmer’s main role and focus should be to imagine new audio-centric solutions to the problems of the game teams and the sound department. This is not the case nowadays. New game designs based on audio analysis, sound effects generated at runtime with procedural audio, perceptual voice management, spectrally-informed mixing, audio shaders, content-aware audio tools: these are only a few examples of what an audio programmer could be working on and which is almost totally absent from our games and pipelines today. This is in part why game sound has not evolved as much as its graphical counterpart.

If you have a programmer with a deep knowledge of audio and have him working exclusively on triggering sound effects, streaming music tracks or on some basic .Net tools, you are missing a world of opportunities. This will be the connecting thread of my future posts, as I try to put the audio back into audio programming and to show all the wonderful things we can do for you, your sound team’s workflow and your games. (Source: Gamasutra)