Rename some cmake target names to avoid conflicts
[openal-soft.git] / docs / hrtf.txt
blob0ea27caa73cee4c0a84b049c77e591495d2dc496
1 HRTF Support
2 ============
4 Starting with OpenAL Soft 1.14, HRTFs can be used to enable enhanced
5 spatialization for both 3D (mono) and multi-channel sources, when used with
6 headphones/stereo output. This can be enabled using the 'hrtf' config option.
8 For multi-channel sources this creates a virtual speaker effect, making it
9 sound as if speakers provide a discrete position for each channel around the
10 listener. For mono sources this provides much more versatility in the perceived
11 placement of sounds, making it seem as though they are coming from all around,
12 including above and below the listener, instead of just to the front, back, and
13 sides.
15 The default data set is based on the KEMAR HRTF data provided by MIT, which can
16 be found at <http://sound.media.mit.edu/resources/KEMAR.html>.
19 Custom HRTF Data Sets
20 =====================
22 OpenAL Soft also provides an option to use user-specified data sets, in
23 addition to or in place of the default set. This allows users to provide data
24 sets that could be better suited for their heads, or to work with stereo
25 speakers instead of headphones, for example.
27 The file format is specified below. It uses little-endian byte order.
30 ALchar   magic[8] = "MinPHR03";
31 ALuint   sampleRate;
32 ALubyte  channelType; /* Can be 0 (mono) or 1 (stereo). */
33 ALubyte  hrirSize;    /* Can be 8 to 128 in steps of 8. */
34 ALubyte  fdCount;     /* Can be 1 to 16. */
36 struct {
37     ALushort distance;        /* Can be 50mm to 2500mm. */
38     ALubyte evCount;          /* Can be 5 to 128. */
39     ALubyte azCount[evCount]; /* Each can be 1 to 128. */
40 } fields[fdCount];
42 /* NOTE: ALbyte3 is a packed 24-bit sample type,
43  * hrirCount is the sum of all azCounts.
44  * channels can be 1 (mono) or 2 (stereo) depending on channelType.
45  */
46 ALbyte3 coefficients[hrirCount][hrirSize][channels];
47 ALubyte delays[hrirCount][channels]; /* Each can be 0 to 63. */
50 The data layout is as follows:
52 The file first starts with the 8-byte marker, "MinPHR03", to identify it as an
53 HRTF data set. This is followed by an unsigned 32-bit integer, specifying the
54 sample rate the data set is designed for (OpenAL Soft will resample the HRIRs
55 if the output device's playback rate doesn't match).
57 Afterward, an unsigned 8-bit integer specifies the channel type, which can be 0
58 (mono, single-channel) or 1 (stereo, dual-channel). After this is another 8-bit
59 integer which specifies how many sample points (or finite impulse response
60 filter coefficients) make up each HRIR.
62 The following unsigned 8-bit integer specifies the number of fields used by the
63 data set, which must be in descending order (farthest first, closest last).
64 Then for each field an unsigned 16-bit short specifies the distance for that
65 field in millimeters, followed by an 8-bit integer for the number of
66 elevations.  These elevations start at the bottom (-90 degrees), and increment
67 upwards.  Following this is an array of unsigned 8-bit integers, one for each
68 elevation which specifies the number of azimuths (and thus HRIRs) that make up
69 each elevation.  Azimuths start clockwise from the front, constructing a full
70 circle.  Mono HRTFs use the same HRIRs for both ears by reversing the azimuth
71 calculation (ie. left = angle, right = 360-angle).
73 The actual coefficients follow. Each coefficient is a signed 24-bit sample.
74 Stereo HRTFs interleave left/right ear coefficients.  The HRIRs must be
75 minimum-phase.  This allows the use of a smaller filter length, reducing
76 computation.
78 After the coefficients is an array of unsigned 8-bit delay values as 6.2 fixed-
79 point integers, one for each HRIR (with stereo HRTFs interleaving left/right
80 ear delays). This is the propagation delay in samples a signal must wait before
81 being convolved with the corresponding minimum-phase HRIR filter.