Despite the claim that it was an 11th order filter, the transition width was
generated by specifying 12th order. A 12th order filter would need 14 sample
points rather than the 12 it had.
The old layout separated filters, scale deltas, phase deltas, and scale phase
deltas into separate segments that each contained a numbers of scale and phase
entries, Since processing a sample needed a filter and one of each delta entry
relating to a particular scale and phase, the memory needed would be spread
across the whole table. And since subsequent samples would use a different
phase, it would jump around the table a whole lot as well.
The new layout packs the data in a way more consistent with its use. The
filters, scale deltas, phase deltas, and scale phase deltas are interleaved,
such that for a particular scale and phase, the filter and delta entries used
are contiguous. And the phase entries for a particular scale are kept together,
so the ~500 to ~1000 samples processed per source update stay within the same
3KB to 6KB area of the 70+KB table, which is much more cache friendly.
Currently makehrtf only handles 24-bit output, not dual-ear, and only when
given the --experimental switch. Files produced this way will not be guaranteed
future compatibility. When the mhr format is also updated with multi-distance
measurements, the experimental switch can go away.
The default number of auxiliary effect slots is now 64. This can still be
raised by the config file without a hard maximum, but incurs processing cost
for each effect slot generated by the app.
The default number of source sends is now actually 2, as per the EFX docs.
However, it can be raised up to 16 via ALC_MAX_AUXILIARY_SENDS attribute
requests, rather than the previous 4.
Both 5.1 Side and Rear configurations use 'surround51' to look up the
appropriate decoder file. The decoder loader already handles mapping between
rear and side channels, so there's no need for separate options.
Similar to how the library handles it, duplicate entries of the same file are
ignored. This could happen if, for example, XDG_DATA_DIRS contains the same
path multiple times.
CMake 2.8.5 added the GNUInstallDirs module, which provides various
variables following the CMAKE_INSTALL_*DIR pattern to allow users a more
flexible installation setup and to provide sensible defaults while
respecting distribution specific install locations like lib64 for RPM
based linux distributions or debian multiarch tuples.
