While examining the successful simulation of environmental audio and aural cueing, one must understand the real issues at hand.

In commercial applications, the first consideration is FAA certification. The reality of the FAA requirements is that they are very loose. The FAA actually only identifies the following as sound requirements (quoted from FAA AC 120-40B):

"... sound of precipitation, windshield wiper, and other significant airplane noises perceptible during normal operations and the sound of a crash when the simulator is landed in excess of landing gear limitation."

This is the sum total of the requirement for Level C certification! There is no quality reference or requirement to be accurate.

For Level D certification (the highest) this becomes:

"... realistic amplitude and frequency of cockpit noises and sounds, including precipitation, static and engine and airframe sounds. The sounds shall be coordinated with the weather representations required in FAR Part 121, Appendix H, Phase III (Level D), Visual Requirement No. 3."

This, again, is loose in the extreme.

In order to place some objectivity on these criteria, it has become accepted practice that test results be presented showing a comparison of the amplitude and frequency content of the sounds of the actual aircraft and aircraft systems in a given operating condition, against the same data produced in the simulator for the same operating condition. The FAA imposes no specific criteria for these tests.

Simulators have been certified using 1/3rd octave spectral analysis, but again, there is no imposed tolerance banding on the range of compliance (typically +/-5dB is used in practice). In reality, you could meet the plot criteria using a number of individual sine waves generated at appropriate volumes.

Acoustic research has clearly proven that the spectral analysis of a sound does not (necessarily) reflect human perception. This can be demonstrated by playing two different sounds with essentially identical perceived characteristics, and then applying spectral analysis which shows entirely different content. Other examples of this are in the use of psycho-acoustically founded compression techniques (such as that used by Sony Minidisc), which essentially throws away spectral data that the system considers redundant.

There are ASTi systems currently fielded that have achieved FAA Level D certification.

Given the FAA criteria, it is possible to make almost any system with at least a certain level of performance meet the FAA requirements. It is more a matter of understanding the operating fundamentals of the system, and applying them.

The ASTi approach uses synthesis as a basis for complex dynamic sounds, usually sounds that change due to dynamic external factors, such as engines, propellers, and aero-noises. Synthesis also allows unusual sounds to be created dynamically, from a toolset of basic waveforms, noise sources and filters.

ASTi has a sampling capability, but in a static sense. A sound, once loaded as a soundfile, can be triggered, and played. Such sounds can be looped, and have the volume adjusted, but not pitch-modulated in real time. This is ideal for sounds such as gear transition/lock, touchdown thumps, missile release, guns, explosions, etc.

Therefore, an ASTi system can take data of varying quality and use it as a foundation for simulation. The data can be used as an acoustic template for the final model, but only where the data is clean enough to allow sampling for static sounds.

One important aspect to consider, however, is that a rough model can be created very quickly from the object-oriented blocks that are part of the Model Builder software. Then, these generic blocks can be highly tuned and customized in real time according to the requirements of the simulation.

Soundfiles are triggered, and the volume and pitch can be adjusted in real time. In this case, however, the final simulation quality is entirely reliant upon the source data, since this is what the sampler is replaying. Or is it?

One major--and unavoidable--fact of life is that aircraft are horribly complex pieces of equipment, and (unfortunately for the sound recordist) if you are to record an aircraft, then you inevitably get a recording of the whole plane, all at once. This is not very useful for a simulation.

Consider the following example:

You record your plane at Mil Power, climb rate 500ft/min, altitude 20,000ft, airspeed 400kts, weather conditions clear. You want to sample the engine, so you do. However, you also have a raft of other noises on your recording like aero-hiss, air-conditioning noise in the cockpit, cooling fans, etc.

You want to use this sample in your simulator, right? But what happens if your simulator doesn't only simulate the plane in the original conditions (Mil Power, climb rate 500ft/min, altitude 20,000ft, airspeed 400kts, weather conditions clear)? What if your simulation starts on the ground with the engine off, and can assume any engine power setting, at any climb rate, any altitude, and so on.

What happens if, in your simulator, you can turn off the cockpit air-conditioning, or make the weather conditions different? So how useful is your sample? It's not! It basically gives you a single reference point only, for a precise set of operating conditions.

Usually, sampler-based systems require an engine to be made up of a number of driven triangle waves and noise sources, which are sampled and then modulated in real time. The source of the sample is usually some kind of synthesizer. This is not to say that it is impossible to sample anything off a recording and use it dynamically. But it requires a very good editing setup, off-line, and usually a raft of additional audio processors.

There is another factor to consider. Let's assume that you do successfully record a sample (i.e., there are no unwanted background noises). So, you decide to pitch-shift the sample. Well, over what range is the sound characteristic constant? For some sounds, this might work, but for some, it will not.

Consider a propeller; there are many factors that dynamically change: blade angle, RPM, blade tip mach effects, airspeed, altitude, and so on. Particularly with propeller aircraft, it is extremely difficult to simulate sounds such as the beat oscillation effects of the prop synchronizers as two props approach synchronization, unless synthesis is used where "control down to the n'th degree" is available over the exact frequency of that generated sound.

Over time, a library of sound samples can be built-up, which can help the sampler-based system. But this is equally true of ASTi systems. One thing that is overlooked most often when using library sounds, is that using a library sound is no different from using a synthesized sound. Neither is based on the source data; so you are no more certain of matching a spectral analysis.

Most military simulators do not even consider the type of requirements that FAA Level D imposes. The most likely "test" will be a subjective assessment by one or more acceptance crews. How does this work?

Well, it's kind of like driving your own car. Over time, you get to know exactly what noises your car makes. Any little change is instantly noticed. "Uh oh! Call the mechanic!" The same is true for a crew of particular aircraft types. The sound signature is very well understood by them. When they jump in the simulator, they will quickly identify any discrepancies, and start throwing them out at the acceptance engineers. They often quickly lose interest and will move on.

The ASTi system is highly tunable in real time. Any synthesized sound can be entirely modified with the system up-and-running, and interacting with the host. New sounds can be added, others taken away, or any aspect of the sound characteristic tuned. This can be done with the crew in the cockpit, and the results can be instantly assessed.

If the changes are good, then the model can be saved and the job is done. The only non-real-time change necessary would be if a soundfile is judged to be fundamentally wrong. The volume of the soundfile can be tuned, as can the trigger criteria. The only reason the sound would need to be changed would be if the core sound was in error (maybe you selected a duck quacking, instead of that missile launch you really wanted!). However, this latter situation is exactly the same as for a sampler-based system, only the sampler system has this problem for every sound.

The tunability of a sampler-based system is limited by the functions available on the sample device itself, and maybe to the flexibility in the original host code that drives the sampler. Our experiences have been less than wonderful.

Usually, a sampler is driven from host code that contains a huge number of lookup tables that provide interpolated values to the sampler. The volume, pitch and on/off status are passed to the sampler for each sound. The sampler may allow some filtering to be applied directly to each sound, and may support envelope shaping (Attack, Decay, Sustain, Release) and relative volume, but not much else.

Therefore, there is only a limited amount that can be done in real time. Any errors in the sound samples must be corrected off-line, additional sounds must be created off-line, and any errors in the lookup tables must be corrected off-line. In some cases, this can result in changes to the host code. Certainly, such changes will not usually be tested within the time span of the original problem identification session.

Perhaps the most important consideration is the ability for the ASTi system to handle both environmental audio/aural cueing and communications. This is a big bonus. Otherwise, you can end up with a collection of different boxes that need to be individually integrated, but we guess this argument is obvious.

SAMPLE AURAL CUE SOUND FILES
Listen to the smaller filesize, demo-quality soundfiles to hear the capabilities of an ASTi aural cue system. The Level C equivalent soundfile (note large filesize) can be used to make qualitative judgements. Click the name of the file to download it.
Name	Time	Sample Rate	Filesize
turboprop.wav	1:36	Demo-quality 8kHz	1.53 MB
turbofan.wav	2:49	Demo-quality 8kHz	2.69 MB
turbofan_hifi.wav	2:49	Level C equivalent 22kHz	7.42 MB